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CHAPTER J 


INTRODUCTION 
STATEMENT OF THE PROBLEM 


Since the introduction of electric accounting machine 


l has become increesingly 


(EAM) equipment, computing hardware 
complex. The interna] speed of computers has progressed 
from the milisecond range, through the microsecend area, 
and inte nanosecend timeframes, Input/output devices have 
increased from 150 cards per minute input and 2090 lines of 
print per minute output to speeds of 2,000 cards and 3,000 
lines respectively. 

The high speeds of the equipment were contrasted by 
the tediously slow pace with which programmers were able 
to write instructions for the computer. In an effort to 
approach a reasonable level of computer utility software 
techniques were developed, These accelerated the production 


and implementation of functional appticattons. The highest 


level programming language currently used, however, is the 





'yhroughout this paper the computing equipment and 
peripheral devices will be referred to as “hardware." The 
program instructions and the related documentation including 
fiow charts, source programs, object programs and test 
data which are necessary to cause a computer to react will 
be referred to as “saftware,® 





ia) 


compiler which facilitates program generation and the 
manipulation of a predetermined array of data. Each array 
or file must be defined, retrieved, and displayed in 
accordance with a previously written program and each 
application addressing that file must follow the same rigid 
format. 

As a result of the information revolution which has 
evolved in recent years, it has become apparent that the 
technological tools must be improved. Managers with a 
minimum of ADP knowledge must be able to extract pertinent 
information from their data bases without the usual lead time 
involved in program development. Software enhancements 
known as data management systems (DMS) are now being gener- 
ated by major software companies under their own trade names. 

This thesis will explore the theory of a DMS and 
investigate the feasibility of employment of such a system 
in conjunction with the U. S. Navy's Chief of Naval Operations 
Command/Management Information System (CNOCOM/MIS). 


SCOPE OF THE INVESTIGATION 
The study will attempt to analyze the CNOCOM/HIS, 
which is currently being produced, to determine the data 
base structure, the intended users, the maintenance require- 
ments, and the operational environment in which the system 


will function. 
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In erder to illustrate the need for a DPMS, such 
areas as data accessibility, file manipulation and display 
reauirements will be developed through a description of the 
total system. The description and subsequent amplification 
will indicate reasons for modular design as well as the 
utility of combining transitional and apocalyptic approaches 


in data base construction. 


RESEARCH/ANALYSIS METHODS 


The nature of the thesis necessitates the extensive 
utilization of primary source material. Reference documents 
will consist of Department of Defense and Department of the 
Navy directives, complemented by surveys, proposals and 
reports generated by the latter department. Studies 
accomplished by civilian contractors regarding CNOCOM/MIS 
will also be used. Personal interviews will relate the 
current stages in develepment of CNOCOM/NIS, the deviations 
brought about by certain events during development and the 
attitudes of the designers, analysts and programmers ahout 
their product. In addition, software/hardware consultants 
will be queried regarding their executive system and DMS 
packages. Technical information to provide guidance and 
evaluative techniques for the overall process of management 
information system (MIS) development will be gatned from 


books and periodicals. 
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Analysis will be primarily deductive, CNOCOM/MIS 
requirements will be pitted against the contrasting capabil- 
ities of DMS techniques and existing software in order to 
determine the system best suited for fulfilling the desired 


objectives. 
ORGANIZATION OF THE STUDY 


Chapter II relates the U. S. Kavy's response to the 
information exploston brought about by computer technology. 
It indicates the evolution of computer utility from World War II 
to the present. Toward the end of this era, it describes 
the efforts put forth by top-level management to achieve 
coordination of systems culminated by the Chief of Naval 
Operations (CKO) in CNOCOM/NIS. 

Chapter III begins a description of CNOCOM/MIS by 
explaining the non-functional subsystems and their necessity 
and relationship in the system. These subsystems are the 
basic driving forces for the total environment and the means 
through which all tasks of CNOCOM/MIS are accomplished. 

The chapter concludes with a definition of the 
data base, its design, construction method, and maintenance 
techniques. 

A description of the six functional CNOCOM/MIS 
subsystems opens Chapter IV. These are the principles and 


rules which will cause the operational applications to he 
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accomplished. They are all dependent upon the non-functional 
subsystems and to a large degree dependent updon their own 
interfacing to fully realize their objectives. 

This chapter analyzes certain kev facets of the system 
in order to show the need for a DMS. It briefly describes 
the system from the user's standpoint and the data sponsor's 
rosition. 

The fifth chapter summarizes facts pertinent to the 
basic thesis question in order to build a conclusion by 
deductive reasoning. The third generation (U-1198) hardware 
system will be briefly discussed followed by long range plans 
and/or ideas for CNOCOM/HIS of the future. 

The final section of Chapter V summarizes the 
conclustons with respect to the feasibility of using a 
DMS in conjunction with CNOCOM/HNIS tn order to enhance data 
accessibflity, processing and report generation by the 


non-technical data processing layman. 





CHAPTER If 


WHO NEEDS AN AUTOMATED MIS? 
THE INFORMATION EXPLOSION 


During World War II, the Navy assisted in the develop- 
ment of electronic computers for scientific and engineering 
purposes. The early computers were used for high-speed 
formula evaluation. The follow-on of these computers provided 
capability for business and logistics work. These computers 
vere constrained severely due to a tack of adequate program 
storage devices. In addition, the software did not provide 
full range capabilities to which the industry is currently 
accustomed. 

The Navy's automated systems development has followed 
an unfortunate pattern of establishing new ADP installations 
as additional applications evolved. This appreach seemed 
Satisfactory in the early phase when the equipment had 
limited capability and slight, if any, means of rapid data 
transmission. Each system satisfied a need, but in most 
cases the acquisition of the system was based on the strength 
of the justification which could be presented by the organ- 


izational segment which had the particular job to do. 
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There was little thought given to future integrated systems 
as each implementer devised his own standards, 

Most of the information systems in the past, and 
some of those still being designed, are concerned with the 
achievenent of more economic methods of collecting, trans-~ 
porting, processing, and displaying information. This is 
not necessarily the same as the organization and the presen- 
tation of pertinent facts concerning alternative choices 
available to the manager for decision-making. 

A wider, more imaginative use is now being developed, 
extending into middle-management and providing “as requested" 
reports on a demand basis. The same data formerly used only 
for routine transactions and scheduled reports can now be 
selected and transformed for management control purposes. 
Third generation computers have moved information systems 
into a new phase. Computers using hugh data banks, now have 
the capability of satisfying multiple users with diverse 
applications. Navy management has become increasingly 
aware of the new benefits to be derived from the computer 
and more areas have been identified where the computer can 
provide greater economies through the consolidation of 
redundant data files and ADP eauipment across functional 


or application lines. 
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ERA OF PLANNING AND COORDINATION 


In 1966, the need for control of ADP and information 
systems became evident in order to realize fully the 
advantages afforded by computer systems. A Presidential 
memorandum of 28 June, 1966, directed all government 
agencies to give thorough study to new ways in which the 
computer might be used. The Secretary of Defense further 
amplified this message by proclaiming that such systems 
should be fully responsive to management's total require- - 
ments and directed the standardization of data systems. 

A study conducted in 1966, at the direction of the 
Chief of Naval Operations (CNO), found a diffusion of ADP 
responsibilities within OPNAV. The study group recommended 
as organizational change. The recommendation called for a 
strong, centralized organization to plan and direct Navy 
information and data systems. %n 28 April, 1967, the CNO 
established the Navy Information Systems Branch; and in 
January , 1968 formed the Information Systems Division 
(OP-91) within the Navy Program Planning Office. At this 
same time Captain R. A. Jones (OP-912), Project Officer, 
headed a study group to consider the needs of the Navy for 


information system support. 
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The efforts resulted in a proposed concept for a Navy 
Integrated Command/Nanagement Information System (NAICOM/MIS) | 
which would meet the needs. The concept, which was approved 
in September, 1968, also recognized the need for a CNO 
Command/Management Information System (CNOCOM/MIS). This 
system would support the needs ef the CNO and the Naval 
Operations (OPNAV) staff, and would serve as the capstone 
of the NAICOM/HIS, and function as the information systen 
in support of the Navy Headquarters subsystem of the 
Worldwide Military Command and Control System (wwMCCS).¢ 
An implementation plan? for CHOCOM/HIS was approved and 
promulgated in early 1969. The objectives of the new system 
were stated as follows: 


a. T0 improve the quality and credibility 
of information at the OPNAV level. 

b. To improve the timeliness of information 
to the Chief of Naval Operations. 

c. To preclude the duplication of infor- 
mation requirements placed on subordinates. 

d. To fully utilize the capabilities of the 
computer to meet requirements. 

e. To provide access to collected and avail- 
able information by all authorized OPNAY 


Tu. s. Department of the Navy, Report of the Nav 
Study Group for avy Integrated Command/Management Infor- 
mation System - t (KATCOMJNTS-TY, July, 1968. 


| ape {LS 


-Planning Research Corporation, "Chief of Naval 
Operations Command/Nanagement Study Report,” PRC R-1388, 
Vol. I, January, 1970. 


3y, S$. Department of the Navy, OPNAV INST 5200.9 
Chief of Naval Operations Command/Management Information 


System, February 9, 1969. 
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users while insuring adequate measures to 
preclude unauthorized disclosure of class- 
ified information, including "need to know" 
safequards. 

f. To be responsive to the information require- 
ments of higher authority. Specifically to 
provide requested operational information to 
WWHCCS and business and logistics information 
as required to the Secretary of the Navy 
(SECNAV) through the Department of the Navy 
Managenent Information and Contral Syster 
(DONMICS). 


EMPHASIS ON INTEGRATION 


As a direct result of the recommendations contained 
in the NAICOM/HIS study and subsequent approval of the 
CNOCOM/MIS implementation plan in February 1969, separate 
but related actions were taken by the CNO Information Systems 
Branch (OP-912). One such activity was an organizational 
review of certain development and implementations of 
information systems. Another task, for which technical 
support was previded hy the Planning Research Corporation 
(PRC), was a CNOCOM/MIS study which was conducted during the 
period April to October, 1969. The objective of this study 
was to develop an operational concept for CNOCOM/MIS that 
would specify the procedures and facilities necessary to 
permit effective staff interaction with this highly automated 


information system. 


libid., pp. 1-2. 
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The Information Systems Division conducted a survey 
concurrently with the above PRC study, to determine the 
information reauirements of the OPNAV offices (OP's) for 
CNOCOM/HIS. This survey consisted of interviews, orcaniza- 
tional and decision center analyses, flow path studies, 
reporting requirements and functional relationships. As 
the study group completed each OPNAV office, they prepared 
Interim Working Papers. After accumulating all of these 
papers they consolidated the data into a ftnal technical 
report! containing survey findings on information processes, 
existing and proposed automated and non-autcmated systems, 
unfilled information requirements and recommendations on the 
possible integration of these into the overall CNOCOM/HIS 


plan. 
CURRENT SYSTEMS ANALYSIS 


The Final Report revealed trat tne Naval Command 
Systems Support Activity (NAVCOSSACT), the Navy Information 
Center (NAVIC) and other Maval installations for which the 
OPNAV offices are sponsors, sources of input, oer recipients 
of output heid a myriad of differing hardware and software 
combinations. At NAVCOSSACT and NAVIC there were thirty-one 


major systems in existence which were utilizing five types 





lu, S. Department of the Navy, NAVCOSSACT Document 
Mo. 40A5M4 TR-19, CNOCOM/MIS Survey of Information Require- 
ments, November, 1969. 
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of central processing unit cenfiguraticns and a total of 

nine different compilers. Many of the systems were written 

in two or more software languages, ceusine further corfusion. 
There were eight systems reviewed which were operated at 
installations other than MAVCGSSACT and BRAVIC. These systems 
enpioyed four distinct hardware sets, five compilers and an 
unrecorded number of assemblers. In addition te the foregoing 
operational systems, twenty new systems were found te be 
either under development or pronesed for development at 

the activities studied. This study bears out the intense 


need for standardization. ! 
REQUIREMENTS IDENTIFICATION 


The total range of systems studied nad been or were 
being developed to. fulfill such needs as: 

(1) Mobilization requirements for Army, Air Force 
and Coast Guard personnel. 

(2) Flag Plot information required by SECKAV, CNO 
and the Joint Chiefs of Staff (JCS). 

(3) Aviation statistics and reports. 

(4) Fuel and ammunition inventories and planned 
requirements. 

(5) Nuclear weapons information. 


(6) Concressional inauiries. 


Seen ae 


“ipid., pp. 15-21. 
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(7) War game strategies. 

(8) Navy cost information. 

(9) Registered publications inventories. 

(1G) Southeast Asian Operations data. 

(11) Manpower management information. 

(12) Research and develenpment and a multitude of others. | 

Aside from the many and varied requirements which 
were being met by the existing systems, the study group un- 
covered stil! more needs that were not being met. FEfght of 
the eighteen 9P Codes surveyed, had such unfilled requirements. 
(OP Codes and their missions are contained in Appendix A.) 
A summarization of the existing systems and future systems 
related to their users are shown in Appendices B and C 
respectively. Appendix D contains a list of activities 
which require additional information and the type of data 
needed by each. 

As a result of the survey, sponsors were assigned 
for each system. However, certain systems generated infor- 
mation which could be used by many offices. An example of 
this is the Navy Cost Information System sponsored by the 
Navy Comptroller but used by ten OPNAY offices. To avoid 
overlap of file maintenance responsibility in these 


Situations where the systems cross organizational lines the 
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Mibid., pp. 8-22. 
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| determined it most feasible to designate only 


study aroup 
the prime or largest user as the sponsor. The spenseors 
responsibiltfty is to purge the system files of unnecessary 
information and update the remainder in preparation for 
incorporation into the CNOCOM/MIS integrated data base. 

The requirements had been identified, and awing to 
the nature of CNOCOM/MNIS the desianers decided that, until 
the system became fully cperational, the users would be 
limited to top-level management ({.e., CHO and his staff). 
The concept would provide for information support to the 
entire CNO staff as well as outstde oraanizations such as 
SECNAV and JCS. The data hase will be maintained by the 
OPNAY organization codes assigned the sponsorship responsi- 
bilities. It fs anticipated by the OPRAV designers that 
in the short range future (5-19 years) that the media 
may be expanded, for both service and maintenance, to the 
middle management echelon at the Fleet level.° however, 
this presupposes major technological advancements in the 
digital data transmission field over the next half decade. 
Concerning this media, WU. MBM. Ellinghaus, President, New York 
Telephone Company, speaking as an affiliate of AT&T stated: 

Tinterview with Sarah Pillar, Head, Data Base 
Subsystem (CNOCOM/MIS) Branch, Nashingten, 0. C. on 
January 25, 1971. 

e Ibid. 
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In the next ten years we plan a four- 
fold increase ... .It will not consist of 
more and more of the same but will fncorporate 
facilities that are in the laboratory today 
and promise vastly increased capacity--at 
lower and Tower costs as the decade unfolds. | 
He further announced that an all digital network (as opposed 


to the existing analog) is planned by AT&T by 1975,2 
SYSTEMS CONVERSION PROCESS 


Concurrent with tne aforementioned NAICOM/MIS Study, 
the PRC Study and the general identification and analysis of 
CNOCOM/MIS requirements procurement negotiations were underway 
for a third generation system to augment the existing 
7090/1401-10 installation at NAVCOSSACT.* Although not 
formally defined at the outset of the purchase action, the 
projected CNOCOM/MIS system requirements were included in 
the specification package established for the new hardware. 
The contract was awarded to the UNIVAC Divisfon of Sperry 
Rand Corporation to install a Dual Processor 1198 system at 
NAVCOSSACT. (Appendix E). While this system is planned 
initially to auqment the 7990/1491-190 the long range plan 
is to convert all existing applications to the 1108. This” 


projection is possible due to the increased capacity and 


EES or ST SE RE kg ELE lly el 


THerbert Nolan, "Moving Business Pata is Big 
Business,” Business Automation, December, 1970, p. 20. 


Ibid. 
Sinterview with John Schauer, Technical Assistant, 


Chief of Naval Operations Information Systems Branch (O0P-912T), 
Washington, 0. C. on January 20, 1971. 
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speed of third generation hardware in conjunction with the 
sophisticated software being designed into CNOCOM/MNIS. 
Together these features will fully utilize the multi-program 
processing capability brought about by the third generation 
technology. 

Maintenance of existing applications necessitated 
further analysis of the existing and planned applications 
in order to bring about the most effective conversicn plan. 
This phase of conversion primarily addressed the total 
system software conversion to the 1108, as contrasted to 
the data base conversion and its integration into the 
CNOCOM/MIS data base. This latter conversion will be discussed 
in Chapter III. 

In the project request, CNO assigned RAVCOSSACT the 
selection of systems and programs to be considered for con- 
version and restricted conversion to these systems where 
a minimum of reprogramming from one language to another was 
feasible. The project request specified three tasks: 

a. Develop guidelines and specific criteria 

in conjunction with the Desion Team for 
selecting systems and programs for 
canversion. 

b. Analyze NAVIC operational programs, and all 
functional area conversion requirements 
provided by CNOCOM/MIS Design Team Members and 
other NAVIC users, in order to develop an 
overall conversion plan. 


c. Prepare a time phased convers]on plan and 
submit to OP-91 for approval. 


ty. Y. Department of the Navy, NAVCOSSACT Document 
Ho. 404510 TR-O1, CHOCOM/MIS Conversion Plan, June 1,1970, 
Appendix D. 
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The evaluation technique used by NAYCOSSACT considered 
the physical and processing characteristics of the system, 
its potential utilization and sponsor priorities. The 
evaluation process itself was divided into three phases 
which were to: (1) establish criteria, (2) gather system 
information pertinent to the criteria; and (3) correlate 
system information with the criteria. 

The criteria developed for evaluation were placed 
into three major groups: status, characteristics and 
processing. 

a. Status--With respect to status, the considerations 
were: The responsiveness of the system to the sponsor and 
its compatibility with the CNOCOM/MIS requirements; the 
relative priority assigned by the sponsor and its expected 
life span; the condition of documentation and availability 
or source material; and finally, the availability of 
analysts/programmers knowledgeable of the system. 

b. Characteristics--The characteristics pertinent 
to a conversion decision which were reviewed were: the 
language or languages used for each program; the number of 
programs; special hardware requirements; special software 
requirements; and the general complexity of the system. 

c. Processing~--The interface requirements, run time 
frequency as well as the estimated time and effort reauired 


for conversion were comprised in the processing criteria factor. 
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During the information cathering phase the NAVCOSSACT 
personnel researched various scurces. In general, the 
information pertaining to characteristics and processing were 
provided by NAVIC. In addition, CNOCOM/MIS module leaders 
provided information pertaining to the system backgrcund 
and potential planned inte the design structure, as will be 
seen in Chapter ITI. 

In the final major phase cf conversion analysis, 
correlation of criteria anc system information, the com- 
patibility of programming languages was given feremost 
consideration. The programs which had heen chosen as bench- 
marks for the selection cf the third generation equipment 
had demonstrated that COBOL and FORTRAN could be adopted to 
compile on the 1108 with a minimum of revision. The cther 
major language used cn the 7939C was the Macro Assembly 
Program (MAP) which was found to be incompatible with the 
1108. Sue to the large number cf progrars existing which 
utilized this assembler, much consideration was devoted 
to the development cf a translator program to convert them, 
Although this method is possible, further analysis revealed 
that most of the programs assembled with MAP were older 
versions and if converted satisfactorily would still rot 
attain the level of scftware sophistication which will be 
required by CNOCOGM/MIS. Therefore, those systems or programs, 


fer which MAP was the principle language, were considered 
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poor candidates for conversion and would be redesigned and 
programmed specifically for the third generation system. | 
There were thirty-four systems evaluated as candi- 
dates for conversion. Fourteen of these systems, consisting 
of 231 runs written in COBOL and FORTRAN, were selected for 
conversion.* At the time of the Study it was estimated that 
707 man months of effort would be required to complete this 
phase of the conversion task. At the present time practically 
all of this phase has been completed. ? 
Seventeen of the systems reviewed were selected 
for immediate or eventual redesign prior to implementation 
on the 1108. These were generally the older systems written 
in MAP. However, in some instances the analysis revealed 
that changes in user requirements made redesign more practical.” 
Finally, the evaluation team determined that the 
requirements for three of the systems could be satisfied by 
software available with the 1108. These were scheduled for 


replacement. ° 


oo 


libid.,p. 13. 


eibid., p. 19. 


“Interview with Sarah Pillar, op. cit. 


wy, %, Department of the Navy, CNOCOM/MIS Conversion 
Plan, op. cit., p. 19. 


*Ibid., p. 18. 
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20 
COMMENTS 


The analysts anticipate that it will take from two 
to four years te accomplish the complete transfer from the 
7098 to the 1108. ! While this timeframe, due to its range, 
appears to be no more than a quess--at least it i$ a beginning 
toward the mammoth task of developing a futuristic computer- 
ized management information system. William Zani, speakins 
with regard to past attempts at system design has stated: 
"Traditionally, management information systems have not 
really been designed at all. They have been spun off as 
by-products of the process cf automating or improving 
existing systems ... .'2 We referred to this inadequate 
method as the “bottom-up” fashion. 7ani continued on to say: 
If the design of management information systems 
begins on a hiah concenttonal level and on a 
high managerial level as well, a company can 
avoid the “botton-up” design phenomenon of 
recent history and begin to develop the real, 
and very great potential of MIS as a teol for 
modern management. 
‘ibid, pp. 19-20. 


euiTiiam N. Zani, “Blueprint for MIS," Harvard 
Business Review, November - December, 1968, p. 95. 


Sthid., p. 100. 
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CHAPTER III 


A LOOK AT EXISTING DATA WITH 
RESPECT TC SYSTEM DESIGN 


Management information system design determines 
the operating characteristics of a system. Fundamental to 
system design, however, is the definition of system objectives 
which must be determined very early in the planning phase. 
Unless these goals are clear and realistic, a responsive 
system cannot be designed. The failure of management to set 
such goals will hamper management's control over the develop- 
ment and the entire operation of the system. Documented 
system objectives prevent ambiguity and serve as the tool to 
measure progress and performance during the development 
and operational stages. 

The design of a management information system also 
requires the definition of system functions which represents 
the operational requirements of the system. It must be able 
to receive, process, store, and produce information as 
required, 

Although management informaticn systems are usually 


file-criented, requiring large files of information which 
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comprise the data base of the system, the system must be 
developed independent of the media that will affect it. 
R. L. Martino, in one of his recent publications, made the 
Statement that, "Ar NIS 4s completely defined when we have 
established its elements ... and the decisions that link 
them."! 

This chapter has been arranged on the basis ef 
Martino's theory in order te give the reader a knowledge 
of the “heart” of the system before studying the interacting 
operational functions/subsystems which will be described in 
Chapter IV. Following the overview of the basic CHOCOM/HIS 
principles and procedural tools which will be described in 
this chapter, there will be a discussion of the construction 


of the data base as a function of the overall system design. 


CNOCOM/HIS DESCRIPTION 


The system is comprised of a series of integrated 
subsystems, designed to fulfil] the present and future 
information requirements of tne OPNAV staff, allowing them 
to perform their support functions in a more effictent and 
effective manner. A subsystem, in the context of CNOCOM/MIS, 
1s a logical grouping of major OPMNAY functions and processes 


so ordered as to provide for the efficient and coordinated 


Tp, L. Martino, MIS-MNanagement Information Systems, 


(Wayne, Pa.: Management NeveTopment Institute Publications, 
1969), p. 91. 
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development cf the entire system, | CNOCOM/MIS is a large 
and complex system created to provide for the information 
support of the CHD and his staff as well as outside organi- 
zations requiring communication interface with the C80. The 
employment of the subsystem technique and other new approaches 
were used in the design and are being used to develop the 
system into a single integrated package. 

The limits of each subsystem are defined by groups 
of related functions, either by deciston-process criteria 
or by informatton-content criteria. The CHOCOM/MIS 
structure embodies twelve subsystems, Six of these are 
considered to be nonfunctional since they are independent 
from, but are used with, any or all of the operational 
programs. The nonfunctional subsystems are: Equipment, 
Software, Data Base, Input, Output, and Service. The 
remaining six subsystems are the operational types referred 
to herein as functional. Included as functional subsystems 
ares Executive, Planning, Programming/Budgeting/Resource 
Control, Command, Staff Services, and Management. A grapnic 
representation of tne interface involved among these sub- 
systems is shown in Ficure III-1. It is an attempt to make 
the functional and nonfunctional distinction more readily 
apparent while illustrating the need for interface among 


the subsystems. 


Ty, S. Department of the Navy, NAVCOSSACT Document 
Ho. 4GA503 TR-01, CHOCOM/MIS System Design Proposal, 
Description and Implementation PTan, July, to70, p. 21. 
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This chapter descrides the development of the 
system's basic tcols prior to any discussion of the 
integrated utilization of these tools in the operaticnal 


system which will be presented in the next chapter. 
NONFUNCTIORAL SUBSYSTEMS 


The term “nonfunettonal," as applied to these 
subsystems, signifies indirect support of system users as 
opposed to those subsystems which are directly mission 
oriented (functicnal). In addition to providing indirect 
support to the mission oriented parts of the system, these 
softrare segments are the framework around which the 
organizational entity known as the CNOCOM/KIS Systems 
Service! is built. The following pages will provide a 
general description of the subsystem's contents and roles 


in the integrated system. 


software Subsystem 
This subsystem consists of a body of coordinated 


2 and the related actions required in order to 


principles 
provide all of the nonfunctional software for CNOCOH/NIS, 


These principles are essential to the subsystem since software 


Yonoconsmis Systems Service is an OPNAV organizational 
entity which operates as an ADP service bureau for OPNAV, 


euPrinciples,” as used throughout this paper, refers 
to a set of working rules relevant to the function being 
described or performed. 
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which will be incorporated into the system will originate 

from hardware manufacturers, software contractors and from 

the existing second generation software with which the 

CNOCOM/MIS must interface. Software can never be assumed 

to be static. It is, and will continue to be, affected by 

the equipment configuration used as well as the hardware 

of the interfacing systems. Compilers and assemblers may 

have to be augmented to facilitate handling of specific 

tasks, but most important, data management systems (DMS) 

must be studied to determine the need for and benefits to 

be gained from such systems. At this time, no DMS which 

has been analyzed will completely satisfy the specifications 

necessary to complement and enhance the advanced system 

being developed. The changing data transmission/communication 

media causes still another software problem. There is a 

continuing effort on the part of telecommunication experts 

to perfect an all-digital network which will permit wider 

computer-to-conputer communication, | 

The principles of this subsystem include: 
(1) Providing flexible selections of 

required assemblers/compilers for 
source/machine languages (e.9., 
"ANSI COBOL," "FORTRAN," etc.). 


(2) Fulfillment of CNOCOM/MNIS-wide 
software requirements. 


‘Herbert Nolan, "Moving Business Data,” op. cit. 
Dp. 20-21. 
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Mainteinine scftwere irterfaces, net 
only among CNOCOM/MIS Subsystems, but 
alec with nicgher, ecuel, or lower level 
systems and communications networks 
(e.c., integratine CNOCCH/¥IS and LDMX 
software). 

Caordinetior of menufecturer an¢ other 
soTtware contributions to tne subsystem, 
includinge its operating compiler/asserbler, 
data management, and special capability 
components, 

Augmenting manufacturer capabilities 
with ether capabilities based on 
demonstrable needs which cannot be 
otherwise satisfied (e.g., software 
[oat Pare tety or automatic flow chart- 
ing). 

Exploiting the direct access capa- 
bilities of the available equipment 
configuration tn consonance with the 
Fquipment Subsystem's principles. 
Providina nonfunctional software support 
in response te functional subsystem 
requirements based on NAVCOSSACT'S 
development and/or selection of the 
cptimum DMS and the need to augment the 
manufacturer's software capabilities 
during various CNOCOM/MIS development 
phases. 

Ensuring software responsiveness to 
equipment configuration or reconfig- 
uration needs, 

Interin consolidation, for mananement 
purposes, of second-generation software 
maintenance pending its replacement 

by third-aqeneration equivalents. 


The Software Subsystem consists of five modules which 


are: Qperating (system); Compiler/Assembler; Data Management 


(system); Second Generation Software; and, Special Capabilities. 


(See Figure Iil-2) 


Tas 


uU. S. Department of the Navy, CNOCOM/MIS System 


Design Propesal, op. cit., pp. 2/-28. 
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Operatin system) module. The operating system 
for the UNIVAC-1108, which is called “EXEC 8" is written 
and maintained by UNIVAC. It operates in a multiprogramming 
node in a multiprocessing environment. Remote input/retrieval 
and asynchronous processing are two of the futures of "FXEC 8* 
which will be exploited to the fullest by CNOCOM/MIS. This 
system provides for efficient communication between the 
user and the equipment in areas of job scheduling and 


input-output (1/0) servicing. 


Compiler/assembler module, All the compilers and 


assemblers will be identified as submodules to this module. 
Those now included are: ANSI COBOL, FORTRAN V, JOVIAL and 
an assembler. Others may be added as required under a 


"Miscellaneous Submodule,"! 


Data management (system) module. Pata Management 


is a vital task in tne development of CNOCOM/MIS applications. 
The more complex the interrelationships of the various 
functional and nenfunctional subsystems becomes, the 

greater the need is for a DMS that can handle files exped- 
iently, effectively and efficiently. WNAVCOSSACT has 

evaluated eighteen systems on this basis and have found 


none to be completely compatible with the needs of CHOCOM/NIS— 


Ty, §. Department of the Navy, CNOCOM/MIS System 
Design Preposal, op. cit., p. 56. 
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Those evaluated identified with their producers are: 

"CFSS“ (Service Bureau Corporation); "COGENT III" (CSC); 

"DIPS" (NAVCOSSACT); “DM-1" (Auerbach); "DMS" (Whitlow); 

"FORGE" (Burroughs); "GIM" (TRY); "GIS" (IBM); "IDS" (GE); 

"IMS" (IBM); "MARK IV" (Informatics); "MIPS" (NMCSSC); "PRISM" 
(Cybernetics); "RAPID" (CDC); “RFMS" (University of Texas); 
"SCORE" (Atlantic Software); "TOMS" (SDC); and "KIMS" (UNIVAC).- 
(A more detailed description of the evaluation process will 


he addressed later in this paper.) 


Second generation software module. The principles 
and acticns related to this module specifically include 
directina, managing, and/or monitoring the second generation 
seftware. By its very nature, in a third-generation environ- 
ment, this module is temporary. Its function will be relegated 
to the capacity of case-by-case maintenance until] all systems 
have been either converted or redesigned for third-generation 
implementation. Conversion or redesign of programs written 
for second generation hardware is necessary in order to fully 
utilize the advantages of increased processing speed and 
the more capable executive software provided in a third 
generation system. After that has been completed the module 


will remain dormant unless it is further required when, and iff, 


‘y. S. Department of the Navy, NAVCOSSACT Document 


No. 51A002 TR-01, A Study and Evaluation of Data Management 
Systems, May 1969, p. 15. 
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more elaborate communication facilities necessitate inter- 


face with second generation software at renote sites. 


Special capabilities module. This module consists 


of seven submodules which. include utility programs and 
routines which will assist programmers in the areas of 
documentation, sorting, conversion, editing and canned 
mathematics routines. Presently avaflable from the manu- 
facturer are “SORT/MERGE,* “PERT,” “MATH@PACK/STAT/PACK,” 
"DOC" and “UNADS.” The last two are text editing programs 
used in preparation of documentation. Programs for 
automatic flow-charting and.simulation, which are not 


available from UNIVAC will be purchased from another vendor. 


Equipment Subsystem 

This subsystem consists of a collection of software 
principles that govern the optimum utilization and integra- 
tion of onesite hardware, remote terminals and communication 
capabilities withia the CNOCOM/MIS workload definition. The 
function to be performed by the Equipment Subsystem is to 
reduce the requirements placed upon it to specific equipment 
tasks providing the necessary interfacing with external 
systems and communications networks. The scope of equipment 
so controlled includes all of that which is required to 
support the CNO and his staff. 

The principles which define the task of the 


Equipment Subsystem are to provide: 
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(1) An integrated network of computers, 
peripheral devices, communications 
and remote terminal configurations. 

(2) Improved reliability and ensured 
continuity cf operation. 

(3) Data precessing and transmission speeds 
capable of concurrently supporting 
a variety of CNOCOM/NIS applications. 

(4) Adequate capacity to meet current and 
future CNOCOM/MIS processing require- 
ments. 

(5) A communications network capable of 
supporting the exchange of secure 
information between remote terminals 
and the NAVIC Augmentation System in 
a timely manner. ] 

(G6) A random access capability. 


There are five modules embodied in the Equipment 
Subsystem which are: Remote Terminal Cenfigquration Control; 
UNIVAC 1108 Equipments; Communications; Second Generation 
Equipment, and Other Conponents. (See Figures ITI-3) A 


description of each of the modules follows. 


UNIVAC 1108 equipment module. The primary objective 


af this module is te provide for expanded data precessing 
capabilities to augment the facility at NAVIC which, for 
years, has been at the saturation point. The recorded 
operating time over the past few years has slightly exceeded 
ninety percent. The idle time ftncluded both maintenance 
and down time. 

In addition to the 1108, a UNIVAC 9300 Remote Ratch 
Terminal at MAVIC will provide the OPNAV module leaders 


ly, S. Department of the Navy, CNOCOM/MIS System 
Design Proposal, op. cit., p. 32. 
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with the equipment necessary to fulfill both their desion 
and production needs. 

This module is extended to include the 1108 and 
its peripheral equipment located at the computer site 
(NAVCOSSACT, Washington Navy Yard) ane the remote terminals 
operated at that site. Any other remotes are considered 
to be under the jurisdiction of, first, the Communication 
Module and, second, the Remote Terminal Configuration 
Module. 

The main interface with the UNIVYAC 1198 Eauipment 
this Medule is the Software Subsystem which assists the 
module in adjusting the mix of equipment configuration 
requirements to meet each user task in a timely manner in 


relation to the needs of all other concurrent users. 


Communications module, The primary task of this 
nodule is ta plan, design and implement a secure network 
to support the exchange of information between user- 
operated remote terminals and the central computer site. 
It will be the responsibility of this module te seek cut 
the most economical, efficient and technically feasible 
means of ensuring secure transmission between the mainframe 
and the anticipated mixture of diverse remote terminal 
configurations employed. Physically, this responsibility 


begins at the point where the data transmission is ready 
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to leave the 1108 and ends when the data enters the first 
element of any remote configuration. All equipment which 
lies between these two points are within the purview of the 
Communications Module Processes which will be included are 
logical switching, routine, multiplexing and queueing, all 
of which must be tightly controlled in order to optimize on 
both time and facilities while guarding the security class- 
ification of the data being transmitted. At the present 
time, there are no media available for digital transmission 
which will adequately handle classified/privileged and 
unclassified data simultaneously. Although such a feature 
was desired in the new equipment, when the procurement 
prepared the specifications for distribution to the hard- 
ware contractors for bidding, it had been eliminated since 
no manufacturer could produce equipment to such a stringent 
specification. | This troublesome area is under further 
investigation since maintenance of national security will 
prohibit mixed-mode operation until a completely satisfactory 
solution is found. This is probably the largest problem 
facing the CNOCOM/MIS environment. Likewise, it will 
probably be the sole factor limiting total system integra- 


tion to top management and depriving the system of nearly 





linterview with Sarah Pillar, op. cit. 
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direct access to the entire range of classified information 


being constantly generated by remote middle-managers. 


Remote terminal configuration control module. The 
objective is to define the requirements for combinations 


of remote I/0 devices in support of the needs of the OPNAV 
staff personne] and the principles to be invoked in their 
use. the scope of the governing principles begins where 
the Communication Module responsibility expires (f.e., at 
the first incoming element of any remote configuration). It 
includes standard interfacing devices required to control 
combinations of remotes and/or perform a multiplexing function. 
Although the data-link requirements have been acknow- 
ledged and addressed by the module leaders in their equipment 
specifications, procurement of the actual remote devices 
has been held up due to a few significant factors which 
continue to be uncertain. One of the major problems to be 
surmounted is the one previously discussed with relation to 
the communications module-security. 
Federal Standard 222 indicates the acceptable level 
of radio frequency (RF) radiation which may emanate from 
data transmission equipment. Three possible alternatives 
have been considered to overcome this problem, which are: 
(1) installation of RF shielding around all terminal devices; 


(2) procure only terminals that meet Federal Standard 222; 
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and (3) request waivers for terminals which will not meet 
the Federal standard, 

First, the cost involved in the shtelding alternative 
could make the use of remotes for handling secure data 
prohibitive. Secondly, as discussed earlier, there are 
currently no manufacturers with equipment capable of satis- 
fying all of the needs of security which includes the 
restraints imposed by Federal Standard 222. Finally, after 
exhaustive research, the module leaders are tending more 
toward the dispensation approach. To date, however, this 
has not been done because it 1S a compromise and is not 


necessarily an adequate solution. 


Second-generaticn equipment module. The scope of 


this module includes the responsibility for all second- 
generation computers and peripheral equipment for which 
procurement has been funded by CNO. It will consist of a 
perpetual inventory of this hardware which is available to 
provide the capability to reconfigure existing equipment 
for which CNO 1s responsible, in the event such an interface 
requirement emerges. When all intended users of CNOCOM/MIS 
have been converted to etther third-generation hardware or 
have been provided with an adequate software interface with 
third-generation equipment, then this module will be phased 
out of CNOCOM/HIS. 
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Other equipment nodule. The primary objective of 


this segment will be to conduct an inventory of equipment 
not included in the other four equipment modules. It will 
necessitate conducting an initial inventory of all such 
equipment which includes, for example, electrical accounting 
machines, reproduction machines and labor saving devices, 
closed circuit televisions, time-sharing equipment (except 
that used in conjunction with the CNOCOM/MIS 1108), and 
third generation equipment other than the CNOCOM/MIS 1108 


configuration. 


Data Base Subsystem 
The Data Base Subsystem is comprised of a set of 


principles and related actions as opposed to the data base 
itself (the accumulation of data upon which the subsystem 
principles and actions are applied). The principles consist 
of a data base maintenance and coordination role by which: 


(1) The data base is updated or other- 
wise addressed, 

(2) Storage locations of randomly-accessible 
data are automated. 

(3) The content of the data base is 
recorded, whether or not part of that 
content itself fis automated, (e.9., an 
automated record of unautomated data.) 

(4) OPNAV--interest date elements and 
their specimens are named, defined, 
coded, and automated (e.g., the element 
"OP Code" and its specimens, "OP-O1," 
"OP-03," etc.). 

(5) OPNAV--interest data is translated into 
one or more of its diverse forms 
needed for total system coordination, 


blo? Mebddaeerl 6h eo! ‘ 
aor? Gets ote © 
A eet el iee The 





39 


(6) Data is arranced for automated filing 
and identified with the fields, 
records, and files in which the data 
resides or will reside. 

(7) Attribute data about units which are 
of interest to the Navy (not necessarily 
Navy's units) are automated, 

This subsystem will be user-oriented and its import- 
ance lies in tne ability to accept data in either uniform 
or diverse form, record it, waintain it, index it, and cross- 
reference it for direct or quasi-direct access dependent 
upon the size of the file and the relative priority of the 
user. Files will include: those of general interest to 
OPNAY users, those of parochial interest, and summaries of 
either or both of the foregoing, 

The Data Base Subsystem consists of five modules 
which ares: Data Base Files Structure; Unit Information; 
Data Directory and Dictionary; Data Translation and Data 


Maintenance (See Figure III-4). 


Data directory and dictionary module, This module 
has been subdivided into two separate submodules by the 
module leader since the functions of the directory, while 
closely related to that of tne dictionary, are quite 
diverse in nature. This emphasis is made by the following 


comparison of the submodule principles. 





". S. Department of the Navy, CNOCOM/MIS System 
Desicn Proposal, op. cit., pp. 24, 26. 
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Birectory Dictionary 
ts Automated data only (1) All data in the base! 
(2 Where data is (in system) (2) What data is 
(3) Coded data location (3) Data names, definition, 
aliases correlation-links, 
etc. 
(4) Coordinated processing (4) Coordinated management 
of data of data 
(5) Indirect discourse with (5S) Direct discourse with user 
user (via seftware) oe. publications, 
etc. 


The Head of the Data Base Subsystem Branch,¢ indicated 
that the most basic distinction could be drawn in the fact 
that the Dictionary contains information concerning data 
elements whether they are automated or net, while the 
Directory's primary function is the lecation of machinable 
data within the integrated data base. She indicated a 
possibility that a "pointer" system may be incorporated into 
the Ofrectory for the purpose of retaining the external 
location of non-automated data. 

This module includes the body of principles and 
actions which soverns the identification of existing data 
elements and their sub-elements (specimens), the required 
establishment of new ones, the cataloging of diverse forms 
of data used to represent the same information, and locating 
such data in random access storage. 

‘nata base used herein refers to the entire reservoir 
of data available to CNOCOM/NIS, regardless of whether such 
data may or may not be automated or physically incorporated 
in a file at a given tie. 


finterview with Sarah Pillar, op. cit. 
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Unit information module. The applicable principles, 
and actions of this module are intended to be used to main- 
tain data specifically attributable to the units that are 
of interest to the Navy (f.e., ships, aircraft, facilities). 
This data wili be both variform and uniform dependent upon 
the files scanned, The principles cf this module are: To 
identify what information about units is required; to 
determine the best sources of such information; to decide 
which data should be automated; to analyze the optimum 
means of tailoring output to satisfy each unit's information 
needs; and, to determine which cata should be extracted 
from existing source data. 

All unit information is subject to the scrutiny of 
the Data Directory and Dictionary Module before it is allowed 
to enter the data hase initially. At one time or other 
the Unit Information Module will be used by every module 
of the Data Base Subsystem as well as interfacing with all 
nonfunctional subsystems as the need arises. It fs also 
expected that this module will interface with most, if 


not all, of the functional subsystems. 


Data translation module. This module identifies, 
correlates, displays for comparative analysis, and trans- 
lates data which exists in a variety of forms into the 


standard form for all of that subject matter (e.g., USS 
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F. D. ROOSEVELT, F. DB. ROOSEVELT and RCOSEVELT would al} 
be synonymous), The concept cf operation cf this medule 
is not only te icentify synonyms cr related variforw elements 
ef data, Gut aise to continuously diminish the size of the 
data bese Ly eliminating syncenymous varifern deta, thus 
reducing repetitton in the files. 

The Input Subsyster (discussed later in this 
Chapter), provides the capability to establish, maintain 
and query any variform cata founc to exist in the date 
base. & predominant version of the variform will be selected 
as the standard by the Data Translation Module. tewever, 
the input of any one of the synenymous variforms will allow 


output of all aynonymous data required by the OPHAV users. 


File structure mocule. The principles and related 
actions of this medule are used to identify all of the 
data files available tc CKOCQH/MIS and the specific content 
of each file. The concept uncer which tt operates is to 
establish one record for each CHNOCON/KHIS automated file. 
It further correlates these records ano generates intra- 
file linkages in order for a relationship to exist among 
related data elements containec in different files. The 
link to all such data will reside in the Data Directory and 
Dictionary Module File. 

The File Structure Module, in addition to establish- 


ing an individual record for each CHOCOM/MIS--interest file, 
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indicates its scope (e.g., Navy-wide), function (e.9., 
logistics), usage scope (e.g., NOD wide), originator (e.9., 
NAVCOSSACT), etc. The output products from this module's 
files will be used primarily by the Service Subsystem for 


data base management and system control. 


Data base maintenance module. This module is 
responsible for ensuring the integrity of the data base 
content by coordination of its input and output supports. 
It will employ input which has already satisfied validation 
criteria of the Input Subsystem and in conjunction with the 
Software Subsystem will provide for all nonfunctional 
requirements for data base maintenance. 

Some of the editing features involved when this 
module is interfaced with functional subsystems (in order 
to ensure complete integrated and standard updating of the 
data base) include: certified access, security clearance, 
identification of input type and its originator, diagnostic 
rejection data and data needed for routing control. 

Auditing capabilities will include tracing of input 
data which was addressed to one or more fields for up- 
dating. This procedure will uncover broken links in the 
updating process, or identify those elements which are 


catalogued for updating regularly, but for which no data 
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has been received in the input cycle. In such instances 
the Data Sponsor would be notified to provide new data or 
have the update flac removed, 

A limited search and retrieval capability, simflar 
to the tracer concept previously described, will be pro- 
grammed into this medule along with the standards and 


operating procedures for the data base query process. 


Input Subsystem 
This subsystem will provide the mechanism for the 


collection of raw information input to the CNOCOM/MIS data 
base and the methods and procedures te incorporate the 
input requirements levied upon subordinate organizations 
by OPHAV into a single systematic entity. By these 
procedures the duplication of input requirements (data 
already being acquired) should be significantly reduced, 
and by working in conjunction with the Data Directory and 
Dictionary Module, the Data Translation Module and the 
Software Subsystem it will provide an effective means of 
controlling the information conveyed to the data base. 

In essence, this subsystem has the ability to 
define the parameters, by which data etther does or does 
not meet the criteria, for induction into the data base, 
and the logic and instructions to determine how the quali- 


fied and/or unqualified elements should be processed. 
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The Input Subsystem objectives and rules as 


follows: 


(1) Increased automation of output 
to OPNAV. 

(2) Reduction of reporting require- 
ments. 

(3) Provision of an inteorated report 
directory and flexibility in sequenc- 
ing directory content, 

(4) Provision of an interface with other 
information systems and programs. 

(5) Streamlining the method for the 
acquisttion, control, validation, 
emissfon, and access for all data enter- 
ing the automated data base. 

(6) Automated support for reports manage- 
ment. 


The Input Subsystem is comprised of three modules: 
Input Requirements Analysis; Input Processing; and, Input 
Management. (See Figure III-5) A description of the 


module follows. 


Input requirements analysis module. This module 


will provide the parameters, methods and procedures necessary 
to determine the sources of data for CNOCOM/MIS. The 
incoming data will be fully analyzed either hy the System 
Service persennel, by computer, or both, in en effort to 
consolidate the reporting requirements placed on activities 
by eliminating duplication and selecting the best source 


to act as Data Sponsor. To do this, all input will be 





lu, S. Department of the Navy, CNOCOM/MIS System 
Design Proposal, op. cit., p. 24. 
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checked against report directories and dictionaries, 


data dictionaries and non-CNOCOM/NIS report inventories. 


Input processing module. This module consists of 


two submodules in order to perform a dual purpose type of 
edit. 

The Edit Processing Procedures Submodule will 
control, edit and preprocess all input data. This could be 
considered a cursory review carried out in coordination 
with the functional component having interest fin the particular 
data. This phase wiil check for such items as classifi- 
cation, priority and certain errors in data in order to 
determine basic modes of operation. 

The Source Data Editing Submodule will include the 
computer programming required for full editing of all 
input data, It will be performed with coordination from 
the functional component developers and will be tailored 
to meet all of the specific editing requirements necessary 
to the functional components and the Data Base Subsystem 
prior to entry into the data base. The input to the 
Input Processing Module will be raw data from any source 
and the output will be validated and ready for entry into 


the data base, 


Input management module. The tools needed for the 
input data management function will be established in this 
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module. They will consist of instructions, controls and 
procedures necessary to manage the entire mass of input. 
A central record will be established for all input data in 
an Input Uirectory. This directory will be used to 
screen proposed information reaquests against extant 
data. It will contain the followtng information pertaining 
to each request that nas passed through the Input Subsystem: 
(1) CNOCOM/MIS Control Number (consecutive numbers 
assigned by System Service personnel) 
(2) Input Identifier (name of the report of input data) 
(3) Classification (security) 
(4) Material Date (date when input data is due) 
(5) Period Cevered by Input (time span of 
data validity) 
(6) Activity Submitting Report 
(7) Data Sponsor 


(6) Transmission Mode 


Output Subsystem 


This Subsystem is a representation of the needs of 
the users of all levels. It will he directly related to 
the functional subsystems and will he geared to the require- 
ments specified by the users. The principles applied in 
the Output Subsystem require the cost-effective coordination 
and control of ali output requirements. Its objective is 


to provide the informaticn authorized to the requester in 
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the medium anc format desired. It will provide interfacing 
metinods, procedures, and certain computer programs nec- 
essary to manage, control and produce the desired output. 
Although most of the programs taflored to specific output 
requirements wil! be accomplished as part of the cognizant 
functional subsystem, all output must ve in conformance with 
the standards and procedures developed in the subsystem. 

The Output Subsystem consists of three modules: 
Cutput Requirements Determination; Output Processing; and, 


Output Management, (See Figure III-6) 


Output requirements determination nodule. From 
tais module, the metheds, procedures and standards for 
analyzing the requirements for information retrieval wil] 
be derived. This capability will support OPNAV through the 


System Service, 


Output processing module. The methods, procedures 
and controls for all eutput producing programs and other 


operational functions necessary to format, prepare and 
assemble output materials will be included in this module. 
The procedures prepared herein include special handling for 
classified data, hioh priority control, and erroneous data 
reutines. External programs used in processing output will 


be controlled, Certain general purpose pregranms will be 
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inherent to this module but these will be strictly routine 
to comrtement the pregramming done in the functional 
subsystems. 

THE Thput he this modute will be the data retrieved 
from the data hase end the output will consist ef this data 
in the form of reports or demand responses which will be 


input to the Cutput Management Module. 


Qutput managevent module. Provided by this medule 





will be the managetient tools required for the coordination 
of scheduling and security systems necessary for preparation 
of the output reacuired by the overall system. Output 
management functions will include: 

(1) Establishment and maintenance of CNNCOM/MIS 
Output policies and procedures. 

(2) Ceaordination of all output, 

(3) Establishment nf concepts pertaining to 
output product acceptability and maintenance of those 
Standards, 

(4) The development of procedures for reworking 
vreviously unacceptable work consistent with the scheduling 
requirements. 

Similar to the Input Management Mcdule, this module 
logs proposed output in a directory for screening against 
previously resistered reports data in the dictionary, and 


formats available in the dictionary, in an effort to prevent 
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duplicaticn by bringing it to the user's attentien. Elements 
Gof data contained in this Cutaut Directory will se: 

(1) CROCON/MIS output Control Number (consecutive 
number assigned by the Service Subsysten) 


(2) Output Report/Data Title (name and brief 


description) 
(3) Cliassification (security 
(4) Activity Requesting Report 


) 
5) CHOCOM/MIS Design Control Number (the individual 


ona 
oe 


functional component's tdentification number) | 
(6) Application Sponsor 


(7) Transmission Mode 


service Subsyster 
This subsystem will praytde the GPNAY staff with the 


system analysis and procedural develoomant necessary for 
the fruition of standardization, integration and the general 
smecth functianing of CNOCOM/!IS, 

It prevides the methods and procedures te deternine 
the validity of new requirements on the data base. Further 
procadures established wit] tnelude such areas as certify- 
Ing author{ity te determine what types of data should be 


ednitted te the data base and who should have access. 


lipids, Appendix 0. 
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Cael 


In conjunction with the Input and Output Subsystems, 
this subsystem will provide the mechanism far determining 
whether the existing capabilities can be reworked to satisfy 
the request or if a totally new requirement has to be 
recognized and a new capability provided. 

The Service Subsystem is made un of three modules, 
which are: Data Base Management; System Control] Procedures; 


and, Customer Services. (See Figure Iii-7) 


Vata base management module. Tais will include pro- 





cedures necessary to support the CHOCOH/MIS System Service 

in the following ways: Coordination of data base requirements; 
Standardization of data type; entry and purging of data 

from the data base; and, maintaining accounting records 

and performing budvet ana pianning functions related to 

the data tase. In all of these instances, there must be 


complete coordination with the Data Base Subsystem. 


system control procedures wodule, Administrative 
nclicy, procedures and contre}s will be a function of this 
module, System Service personne!) wtll perform the following 
functions under tiie authority delecated by the Certifying 
Authority, the Vice Chief of haval Operations (VCNG): 
designation of organizations to perform functional roles; 
cranting authorization fuer access to data; recemmencation of 


designated users to VCNO; approval of data request cancellations; 
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development of budget and planning information for CNHOCOM/MIS; 


and, selection of data sources. 


Customer service module. The personnel included 
within the scope of this module carry out the procedures devel- 
oped for them by higher authority. Their tasks will include: 

(1) Vaiidation of user requirements 

(2) Compilation of user subject--interest listings 
(user profiles) 

(3) Preparation of data sponsor/user designation 

(4) Assisting users in specfying requirements 

(5) Analyzing requirements against existing data 
base content 

(6) raviding programming service (limited) 

(7) Maintenance of system software integrity 

(8) Recommending Application Sponsors 

(9} Identifying sources and inittating action to 
obtain data for users 

(10) Administering access authorizations 

(11) Providing ADP technical advice or referral 


as requested by users, 


DATA BASE CONSTRUCTION 
The data base of a management information system 
must contain elements structured in such a way to form a 


workable base for the system operation. If the nonfunctional 
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subsystems designed into a system could be referred to as 
the “heart” of a system, then certainly the data base would 
be considered to be the “lifeblood” of that system. Without 
the latter element the former has no need to function, and 
without the former the latter is useless. | 
In the CNOCOM/MIS concept, the middle management 
echelon will provide the top management staff with input 
for the data base. This data will be adequately massaged 
by the appropriate OPNAV offices to check it for validity 
before it is given to the System Service personnel for input 
to the system files. (See Appendix A) Top management can 
then query the data base for information to assist in 
decision making and policy planning. 
“The information elements in the data base must 
be structured into a workable information base. This 


iw and is one of 


structuring is the key to the system... 
the most important considerations to the designers. The 
degree of relationship and integration of the data elements 
will vary considerably depending on the source of the 
elements, the mix of the variables used in a solution and 
the objective of the user. Ideally, however, a code or 


descriptive data field will be constructed in such a manner 


linterview with Sarah Pillar, op. cit. 





eNorman L. Enger, Putting MIS to Work; Managing the 


Management Information System, : 
Management Assoc., Inc., 1969), p. 41. 
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that it will suffice for the needs of any user. For 
example, a Unit Identification Code (UIC) should connote 
the same meaning to the Captain of a ship as it does to the 
Comptroller of the Navy, the CHO, or the Secretary of 
Defense,. Any deviation from the standard UIC must be desig- 
nated by another name and unique characteristics. 

Faced with the formidabie task of developing a data 
base strong enough to support CNOCOH/NIS, the members of the 


Data Base Subsystem Branch began their chore. 


Utility of Data 
The tools available to the team, whose project it 


was to construct the CNOCOM/HIS data base, consisted of the 
results of the previous studies and the survey discussed in 
the background contained in Chapter II. The primary ocbject- 
ive of the survey held in 1969 was to determine what infor- 
mation systems were in existence within OPNAV; second, to 
determine if the systems were fulfilling the needs of their 
sponsors; third, to evaluate the validity of need for the 
data betng generated; and fourth to determine what addi- 
tional data were required by the sponsors that were rot 
being furnished by the existing systems. 

Altheugh the intent of this survey was not to 
identify and analyze each data element being used by the 


many sponsors, the results pointed out that the information 
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could be categorized by sponsor, since each spansor 
required a degree of unique data. It was recognized by 


l that there was a consider- 


the data base designers/analysts 
able degree of commonality between users but the survey 
was not sufficiently definitive to indicate accurate percent- 
ages of such “cross-organizational-iines" data. This is 
still an unknown factor. However, as the files are actually 
constructed the file levels technique to be employed will 
cause the appropriate links to be made between the files. 
As a result of having the sponsor update his own data, 
associated files will also be updated. Therefore, while it 
is necessary to recognize the existence of commonality, it 
will be self adjusting in relation to its accessibility and 
maintenance. 

By investigating the results of the survey (Appendices 
B, C, and D) and conducting more exhaustive interviews 
reqarding file details with the OP code personnel, the Data 
Base Subsystem team was able to determine that approximately 
75 percent of the information requirements critical to the 
performance of the OPNAV mission are currently contained 
within the existing systems. Having made this discovery, it 


was necessary to: decide whether to use this data or begin 





Vinterview with Sarah Pillar, op, cit. 
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anew in the task of data base construction. while there 

is agreement that a gradual conversion to an MIS is necessary, 
there is not always agreement as to whether the new impie- 
mentation should use the existing historical data files. 

Robert VY. Head, has addressed this problem. tie refers to 

the alternative approaches as “transitional” and "apocalyptic." 
He goes on to explain his terias as follows: 


Advocates of the transitional approach 
argue that, since an MIS {s largely para- 
Sitic anyway, it is only tegical to try to 
interface it with existing files and systems. 
They argue further that the typical company 
has an erroneous investment ... in these 
systems, and that this investment must be 
protected and written off over as Jong a 
pertod as possible. 

Partisans of the apocalyptic philosophy 
base their arguments largely on indictment of 
the efficiency and adequacy of existing systems, 
asserting that it is better to start anew 
than to pour geod money after bad attempting 
to perpetuate “second generation" system 
concepts into third cr perhaps fourth 
generation management information systems. 


The decision reached by the team was to use what 
seened to be the best of each approach to develop the base, 
By design, CNOCOM/NMIS was never intended to be merely a 
parasite but to be a dynamic system which would make the 
data integrated into the data base work for the system. 

In this respect the decision could be seen as having 


“apocalyptic” tendencies. However, the designers felt 





Trobert V. Head, “The Elusive MIS," Datamation,Vol. 16, 
No. 10, September 1, 1970, pp. 25-26, 
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that it was more economical to salvage as much existing 
data as possible without approaching the threshold of 
“pouring good money after bad." This measure of utilizing 
existing data files could be considered the transitional 


part of the decision. 


Data Sponsors Assigned 
After reviewing the OPNAV requirements, the Data 


Base personnel determined that each OP-Code would be 
designated as the Data Sponsor for all the information 
contained in its existing systen files. As Data Sponsor 
each OP-Code was instructed to analyze the specific data 
elements in each separate system in relation to the current 
requirements of that office. This analysis, which is 
presently being accomplished, will produce levels of infor- 
mation greuped into cata elewernt families known as data 
sets. The major classificaticn of each family unit will be 
distinct from the others. The sub-levels of information 
within each family will describe specific aspects of that 
information family. Hhile each family unit will exist 
independently within its own boundaries, the units may be 
assoctated with each other to describe a larger universe 

of which they are all members. A more detatled analysis 

at the sponsor level will then scrutinize the synonymous 


Gata elements to determine if standardization exists or 
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is feasible. Element name, Field stze and fietd configuration 
(f{.e., alnhabetic, numeric, special character or combinations 
with regard to character position) are those factors which 
rust be in complete agreement with the parent data elonent 
hefore the data element being compared may be called a 

synonym will be allewed to remain in the data base. It 

will be se identified by means ef the Data base Pictionary 
which will link Synonyms to a cemmon definition. However, 

if the synonymous tittle is not needed for clarity it wil! 

be replaced with the standard title by the Data Sponser. 

Such a review end analysis will be cenducted by Data 
Sponsors until each data element is massaged and purified, 
Each new element will then be manually annotated on a form 
and keypunched into a standard interim format to be used 


for loading the cata base. 


Data Directory and Dictionary 


The interim format will be used since, by design, 
no data shall at anytime be incorporatec directly into the 
data base. It must first withstand the ricors cof stringent 
machine validation, Fellowing this validation, cach element 
will be subjected to an automated Data Translation in order 
to perform a Data Dictionary review, as tndicated earlier, 
te determine commeneality between requirerents of different 


Data Sponsors, or of those elements cverlookedc by an 
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individual Sponser while performing his edit. If found 

te be a synonym with en existing data clement, its name will 
be recerded in the dicttonary with cther information npertin- 
ent to that data element. The new Synonym will then be 
recorded in the Pata Directory as = sub-element of the 
parent data element. It is this file which will contain the 
address of that data in the CNOCOM/MIS data base. hen 

date is updated and the Data Dictionary indicates that 

there are applicable synonyms, the Bata Directory review 
will further identify the additional records and files which 
must also be updated. Likewise, this same kind of chaining 
is accomplished each time a query is received so that all 
existing data available in the data base may be reviewed 

for possible extraction to satisfy the user's requirements. 
It ts an extremely important facet in the design of the 
system since all information cannot reside in the computer 


memory simultaneously for manipulation. 


Functional Structure 
While studying the multitude of requirements placed 
on the system by OPNAY users, and the classes of data needed 
to respond te each user's need, it became apparent to the 
data base desi gher’: that a functional division of information 


seemed most feasible. The functions selected were ships, 





linterview with Sarah Pillar, op. cit. 
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aircraft and facilities since these seemed to tnctude all 
facets of the ilaval establishment. Sy this functional 
segregation it was possthie te have the same group of cata 
sponsers responsible for an entire function. This eise 
facilitated initial data base constructicn since the Sponsors 
existing files were generaily built around these functicnal 
areas. 

Vithin each functien will be the data necessary to 
define and/or describe that functional area. That inforna- 
tien wili primarily consist of data sets, or units of the 
overall function (i. e., a ship, an aireraft, a facility 
would each be one data set within the specific functional 
area). Each data set is then described by the elements 
which make it up along with information about it. Some 
of these subsets include the static identification features, 
planning milestones, movement activities, manpower, 
materials required for {ts support and other pertinent 
information categories. This blending of information 
pertaining to the lowest element of a functional area into 
a record/data set which will completely describe that unit 
is the objective of integration. It is difficult to achieve 
and, although viewed by many as the epitomy of a management 
information system, it is necessary ta, first, determine if 


such a data base is feasible and, second, wefgh the benefits 
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Generated by such integration in relation to the cost 
to attain it. 

Cost-benefit analysis was dane by the team cen- 
structing the data base and 7t was decided that the best 
Flexibility could te realized by Yormulating two files for 
each data set (both of which will resice in direct access 
aewety):' Since top management rarely queries a file to 
retrieve data pertaining to a single unit (data set) a 
ceternination was wade that such information would be 
maintained in a Unit Information Bodule (UIN) file which 
is immediately accessible to but not @ part of the inte- 
grated Data Base (IDB). This file will provide th 
organizaticnal definition of the unit; the component parts 
of that unit; and, it will maintain associations allowing 
units to be grouped during retrieval through use of the File 
Structure Module. The Unit Information Module will interface 
with the Directory in order to perform IDB accessing in 
either direction. 

The IDB will contain organizational type of infor- 
mation pertaining to each unit. Such information would 
include (using a ship as an example) the fleet to which 
assigned, geographic location, scheduled deployments, read- 


iness indicator, funding command, type commander, flotilla, 
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squadron, home port, etc. The UIN file will include: Ship 
class, current status code, days in status, acceptance data, 
contract number, personne! strength, pertinent ship 
characteristics, etc. There is a definite reason for 
splitting the information in this way. The UIM file will 
include all data pertinent to the unit as an entity in 
itself while the ID8 will contain information which focuses 
on that unit's relationship to the overall Navy structure. 
While the IS8 updating will most likely originate with top 
management, the UIM file information will be channeled up 
from lower and middle managers for updating. 

The two files will be securely linked by an Internai 
Organization Structure Code (10SC). (See Appendix F) Each 
unit regardiess of file, will be identified by this code. 
Likewise, all queries will bear an IOSC configured the same 
as the unit's I0SC for immediate accessing to the unit data. 
The query I0SC, however, will differ from the unit I0SC's 
in that only those characters designating levels of infor- 
mation pertinent to the desired response need be coded in 
the qurey I0SC. The others will be left blank. For example, 
if the query demanded informaticn pertinent to ships and 
aircraft under a certain Type Commander's cognizance, then 
the lowest level indicator in that I0SC would be Type 


Commander and all units under his responsibility weuld be 
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included in the response. If, on the other hand, a query 
was made concerning the personnel strength of a specific 
aircraft carrier, then the query IOSC would specify the 
code for that ship. 

When the UIM file is queried for unit data, certain 
extended information will be retrieved from association 
tables by means of an Association Table Reference number 
(ATR) contained in the UIM file and identifying the specific 
table. The reason for this method is to abbreviate the 
record size as much as possible while maintaining adequate 
linking capability. This also provides additional flex- 
ibility since voluminous tables may be added outside the 
VIM or IDB while only adding a single ATR to the unit's 
records. 

In addition te providing the capability of linking 
the IDB to the UIM file by unit (ship, aircraft or facility) 
and the UIM file to the tables associated with specific 
units, it will also be possible to correlate the data between 


the functional areas for updating and retrieval. 


Updating Files 


The Data Sponsors will be responsible for the main- 
tenance of data within their cegnizance. This wil? be no 
burden for those elements which they maintain for their own 


use. However, they will be responstble for certain data 
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which is required primarily by other users. It is very 
possible that these elements may be overlooked. For this 
reason, date will fall into three basic categories recarding 
maintenance: 

(1) Those elements which may lie dormant for 
extended periods but which must be readily available for 
manipulation, 

(2) Those elements which must be updated period- 
ically merely due to thetr dynamic nature. 

(3) Those elements which will require updating if 
a related element 1s changed. 

It is apparent that the first class of data will be updated 
as required. In order te ensure appropriate and timely 
maintenance of the second class, the Rata Dictionary wil} 
contain an indicator designating each dynamic element as 
well as an update code. On a monthly basis the Dictionary 
will be scanned to determine if there are any of these 
elements which have not been updated in the time period 
indicated by the cede. All such elements will be flagged 
and the Data Sponsors notified of the condition. The third 
class of data will be called "trigger elements." These 
will be coded in the Dictionary so that any change in a 
related element, either by direct input updating or by a 

Vy, S. Department of the Navy, NAVCOSSACT Document 
No, 888911 FD-01, DATAMAN III, 18 December 1970. (Draft) 


(Use of this Document authorized by Captain W. 8. Anderson, 
Head, CNOCOM/HIS Branch, OPNAV on 21 January 1971). 
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computational updating, will cause the associated data 
element to be updated also. The update value of the 
"trigger" element may not necessarily be the same value as 
the element being directly affected, but the value will he 
changed as necessary to maintain the desired relationship 
between the two elements. The "trigger" element could be 


viewed as 2 reactive element. 


COMMENTS 


It should be apparent frem the narrative pertaining 
to the nonfunctional subsystems that the intent of CHOCON/NIS 
is to create a system of interrelated modules controlled 
by the basic design principles in order to be responsive 
to CNO's total requirements cr those segments which make 
it up. 

In addition, the description of the data base 
construction being held within the constraints of the above 
principles, should point out the extensive measures being 
taken to keep the design modular to the lowest level. 

(i.e., each element accessible through the Data Directory 
and Dictionary Module). D. C. Foster, (Code 19), NAVCOSSACT 
expressed the need for modularity and the resulting flex- 
ibflity when he said. 
This is the thing that spawned the 
concept of CHOCOM/NIS . .. , CNO is a single 


organization when viewed from one perspec- 
tive and a complex of organizations when 
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viewed from other perspectives. There- 
fore, what we want to do {s come up with 
a system that will serve the single 
organization in the one sense, and the 
various components of this complex or 
network of organizations in another 
sense. If you want to serve the complex 
organization, it means that there is a 
common intersection somewhere regarding 
the data elements in the data base in ; 
their relayancy to the various components. 


This type of systew necessitates interface require- 
ments far beyond the feasible capabilities of second 
generation system. Furthermore, even third generation 
executive softwere systems are not capable of interfacing 
files and hardware in the magnitude required. Existine 
compilers cannot support the system fully, but comple- 
mented by a data management system file manipulation can 


be accomplished efficiently and effectively. 


linterview of 0. C. Foster, (Code 10), U. S. Naval 
Systems Support Activity, Washington, 9. ©. on January 21, 1971. 








CHAPTER IV 


THE SYSTEM RESPONDS 
FUNCTIONAL SUBSYSTEMS 


To this point, tae discussion has been primarily 
concerned with the basics of CNHOCOM/MNIS, i.e., the tools 
which wilt manipulate the system. Thea tools described have 
been the six non-functional subsystems, which are subservient 
to the user's wisnes, and the data base which is at the user's 
command, The system as descrited to this point could be 
compared to an automobile production line fully manned, 
having all of the parts available, but not producing output 
until it is given specific directions as to which style should 
be built. When a valid order is received by the line controlling 
device, the line and materials begin to react in a coordi- 
nated fashion until the completed car is assembled. Likewise, 
CNOCOM/MIS with its utility subsystems and data hase is 
primed and ready to receive a command to accomplish some work. 
In this case, however, the command will be received from one 
or more of a series of functional subsystems. 

Unlike the foregoing subsystems, these are the 


operational user-interface principles for the entire CHOCOM/MIS 
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System. &ii OPNAV requirements, inciceted by the previously 
nentioned survey, wiil be satisfied by these subsystems and 
their moduies. In addition to the non-functicnel subsystems 
giready described, analysis and consolidation of OPNAY 
requirements resulted in 2 projected need for six more 
distinct subsystens as follows: Executive, Planning, Command, 
Management, Staff Services, and Precgramming/Lucgeting/Resource 
Control. Commander QG. &. Morrison, Head, Systems Design 
Section, OPHAV said, 

Tne twelve subsystems are necessary in order 

to enable us to break the large "monster" down 

so that incremental assignments can be given te 

people to work on without getting them bogged 

down in the detaiis of the whole complex system 

- « « Without such an approach the sheer 

weight of the system would scare "hell" out 

of the people involved. 

This chapter will contain a brief description of the 
functional subsystems, their modules and asseciated files, 
followed by an overview of the intended operation of all of 
the subsystems. The discussion will then turn to the 
factors involved in querying user requests relevent to their 
assigned priorities, anticipated hardware extensions and 
anticipated software enhancements. 


Vinterview with Commander Quinn 8. Morrison, SC, 
USH, Head, Systems Design Section (OP-912D) on October 15, 1970. 
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Executive Subsystem 
This subsystem is a body of principles and actions 


directed toward providing the CNO, VCNO and Operating Deputies 
(OPDEPS) with summarized information according to their needs. 
It is expected to function as the primary source of manage- 
ment intelligence for this level. While there will be needs 
for summarized reports, most of the CNO's requirements will 
be on an “as required” basis to be eventually replaced or 
Supplemented by a near real-time exception reporting capability. 
In addition to providing a central infermation source for 
top management (CNO, VCNO, OPNAV), it will provide an inte- 
grated picture of CNY responsibilities, adequate display 
facilities, and the ability to highlight probtems inconsis- 
tent with the existing objectives, plans and goals. 3y 
analyzing information pertinent to tne request and provid- 
ing aids to determine alternative solution paths, it will 
establish an environment for deciston-making. 

The Executive Subsystem consists of three modules: 
Objectives and Plans Module; Project/Program Status Module; 


and Problem Reporting Module. (See Figure IV~1) 


Nbiectives and plans module, This module will 
provide the executive level with the canability of measuring 
technical progress in research and advanced develonment areas 
and of evaluating plans and objectives in relation to the 


overall goals. 
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To perform these tasks, this module will 
interface with most of the functional subsystems, but 
especially the Management Subsystem described later in 


this chapter. 


Project/proqram status module. This wnodule will 
depend primarily on the Programming/Sudgeting/Resource 


Control (P/B/RC) Subsystem for generation of required 
information. Utilizing that information it will provide 
summarized briefs to CNO, VCNO and OPDEPS for decisions 
regarding competing military programs. To aid in the 
decision making, this module will provide an analysis of 
trade-cff alternatives weighing existing environmental 
factors and the costs and benefits that will be encountered 


by each alternative presented, 


Problem reporting module. The intent of this 
module is to monitor all of the functional subsystems and 


their related files in order to detect emerging problem 
areas. To accomplish this, a continuing comparison of plans 
and policies in relation to the Navy's overall objectives, 
plans and goals will take place. ODOeviations from the overal! 
guidelines will be brought to the attention of top nanage- 
ment and when found to be within the system's capability, 
alternative recommended remedial courses of action will also 


be projected. When the system software does not hold the 
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capability to construct and prescribe the recommended 
courses of action, the module will cause all of the facts 
to be collected and evaluated, The resulting display in 
this situation would be the facts considered pertinent to 


an analysis of the problem by the manager involved. 


Planning Subdsvsten | 


This subsystem ts designed to provide the OPNAV users 
with the information required for Joint Forces and/or Navy 
Planning. CNOCOM/MIS planning information ts intended to 
support the OPNAV users in decision making concerning the 
following activities: 


(1) Navy input to joint stratesic plans ; 
and studies. 

2) Navy strategic plans and studtes. 

3) Review of joint papers for strategic 
planning and policy implications. 

(4) Strategic guidance for research 
development, test, and evaluation 
needs. 

(5) Reviews of general and contingency 
war plans. 

(6) Strategic planning guidance for the 
information of Navy force levels. 1 

(7) Joint operations planning and support. 


The Planning Subsystem is composed of four modules: 
Strategic Planning, Qperation Planning; Operations Support 
Planning, and Modeling and Gaming. (See Figure IV-2) 





Vy, S. Department of the Navy, CNOCON/NIS System 
Design Proposal, op. cit., pp. 38, 40. 
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By means of its modules, this subsystem previces information 
interface with the Management, Command, and Programming/ 


Budgeting/Resource Control Subsystems. 


Stratecic nilanning module, This module includes two 





interrelated submodules. While both submodules are structured 
tc support the Navy Planning System, which in turn supports 
the Joint Strategic Planning System, it was felt by CNHOCOM/MIS 
designers that a division of Navy and Joint information would 
best serve the purpose. 

the Havy Strategic Planning Support Submodule objective 
is to facilitate the proper staffing and backup of the avy 
force structures and resource requirements resulting in the 
proper allocation of available funds to meet prescribed 
missfons. Three applications are contained in this submodule 
which ultimately generate three specific planning documents; 

(1) Navy Strategic Study (NSS). 

(2) Mavy Capabilittes Plan (NCP), 

(3) Navy Long Range Objective Plan (NLROP). 

The Joint Chiefs of Staff (JCS) Planning Support 
Submodule provides the coordination and finalization necessary 
to enable Navy inputs to be included in subsequent joint 
documentation. While the efforts of this submodule will not 
culminate in actual finished documents, it will prepare all of 


the Navy information required (except intelligence or losistics) 
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for inclusion in the following five document types. 


(1) 
(2) 
(3) 
(4) 
(5) 


Joint Strategic Operating Plan (JSOP) 


Joint Strategic Capability Plan (JSCP) 


Joint Long Range Strateaic Studies 


Joint Research and Development Cbjectives Document 


JCS Papers 


This module will interface with various other subsystems of 


CNOCOM/MIS (functional and non-functional) in order to 


assimilate all available information into the integrated 


responses required by CNO, JCS, SECDEF and the President. 


Operation plenning module. The objectives of this 


module are to provide the procedures and ADP support to 


accomplish the following four tasks: 


(1) 
(2) 


(3) 


(4) 


Assist in more effective review of 
operational plans submitted by the JCS; 
Provide effective and efficient pro- 
cedures for forwarding operational 
planning reports to the JCS; 

Establish more orderly methods of identi- 
fying, reporting, and processing force 
and resource shortfalls identifted dur- 
ing the operational planning precess, and 
Provide operation planning information 
required by other subsystems and modules. 


a 


In order to perform these tasks, the Operation Planning 


Module has been divided into two submodules, Plan Review and 


Tinid., pp. 73-74. 


8&0 


Joint Reporting Structual. Through the use cf a number of 
separate applications the Plan Review Suomodule will assist 
the OPHAV planner in evaluating the position and capabilities 
of the Navy with regard to meeting specified operating plans 
(OPLAN). It will compare the current assets contained in 
the Integrated Data Base (IDB) with the requirements needed 
to accomplfish the OPLAN and identify shortfalls of manpower 
and material. Alternative resolutions will be generated in- 
cluding movement requirements and the scheduling of such 
movements. Finally, the Plan Review Submodule will coordinate 
all of the foregoing types of processes and compile the official 
Navy review of the Commander in Chief (CINC) initiated OPLAN. 
The Joint Reporting Structual Submodule is designed 
to provide the current reporting requirements for the National 
Command Authorities and al] DOD agencies which directly 
support military operations. It will be responsible for the 
followings identifying these requirements and preparing a 
catalog containing the name of each report, a description of 
the report format, punch card formats, magentic tape label 
formats, and transaction codes. This catalog must be 


periodically updated by a joint group. 


Operations support planning module. Since the 


logistics aspect was excluded from the Operation Planning 


Module, this module will provide the supply and logistics 
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planners in OPNAV with improved capabilities for determin- 
ing their requirements for both operation and contingency 
plans. The module has been further divided into five 
submodules which are: Planning Reference Data; Material 
Support Planning; Transportation Planning; Facilities 
Planning; Navy Support Plan. 

The Planning Reference Data Submodule will create an 
automated file of selected portions of logistical reference 
manuals and ships characteristics data which will be readily 
accessible on-line when an OPLAN is received for review and 
analysis. Much of the data for this file will be obtained 
from the various Naval Systems Commands. Where necessary 
to construct loading plans and the like, information will 
be received from the other services, JCS and DOD. 

The Material Support Planning Supmodule will aid 
logistics support planning in the area of material analysis. 
When evaluating a contingency plan, it will generate 
estimates of supply requirements. This information along 
with data concerning production lead times and stockpiling 
sites will be invaluable to the OPNAV planners. 

The Transportation Planning Submodule will also 
Support logistics support planning. When confronted with a 
contingency plan, this submodule will generate the estimated 
requirements for the mobile logistics support force ships, 
the pipeline shipping requirements, and port throughputs for 
all suppliers utilized by deployed Naval combat units. 
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Such information will assist planners in the overall supply 
distribution plan ineluding positioning of reserve stocks 
anc port workloads. If the centingency plan is found 
infeasible owing to the inability to satisfy the require- 
ments, the information formulated by this submodule will 
assist in the planners’ modifications. 

The Facilities Planning Submodule will assemble and 
coordinate ali taformation pertaining to Navy shore facilities. 
It will be able to provide the capabilities (excluding air) 
for all such facilities. This information will fall into the 
categories of port ltoading rates, storage capacities, berth- 
ing, etc. The indication of shortfalls fin these areas will 
point out where the needs for military construction are 
most predominant. 

The Navy Support Plan (NSP) Submodule will contain 
the principles and procedures to develop and maintain a 
file containing the projected force structures based on the 


currently approved NSP/JSOP forces. 


Modeling and gaming module. This module will support 
the entire Planning Subsystem by providing computerized 


multi-level siwulation techniques. The simulation will 
include either Navy or Joint Forces, and the tactics will 
encomeass military situations ranging from unilateral and/or 


logistic operations to multi-sided nuclear strategy in a 
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general war environment. The data fille will be constructed 
in a modular fashion. The purpose of this design is to 
permit modular interchangeabiliity to create a more realistic 
environment during stmulation. 

The Hodeling and Gaming Module consists of four 
submadules, which are: Strategic Gaming; Contingency Gaming; 
Tactical Simulation; and Logistics Simulation. 

The Strategic Gaming Suhnadule, utilizing five 
separate apnlicattons will develop, document, maintain and 
utilize the gaming models and parametric data for two-sided 
aqeneral war situations in support af OPHAYV requirements. 

The Contingency Gaming Submodule will utilize twe 
applications to develop document, maintain and implement ifts 
models and parameters for gaming two-sided contingency or 
Timited war situations, 

The Tactical and Loeatsties Submedules will generate 
the basic models to be evaluated by an tncorporated into the 


broader Strategic and Ccntingency Submodules. 


Command Subsystem 
This subsystem will support the CNO in the exercise 


of his command responsibilities ever the operating forces. 
Decisions derived by this subsystem are not product-ortented 
as in the case of a decument generated to predetermined 


specifications and format such as a budget. It is actually 
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a byproduct of the decisions previously made in other subsystems 
and todules. Tae output can be viewed as a resumé of dect- 
sions tu date, tie degree of compatibility of these cecisions 
toward attainment of the CHO's goals, and a pointer to 
deviations which could be petential weatnesses. [ft will 
assinilate three types of information: Operations, readiness 
and intelligence. Sy the same token, there are three modules 
to acconpiish these undertakinos: Operations, Readiness 
Analysis, and Intellfgence. (See Figure IV-3) 

Operations module. Information necessary to provide 
CHO and OPNAY with current and projected operational status 
1S contained in this module. The data will tnclude movenents, 
enployments, caSnaities and the overall readiness of afloat 
units as determined from Operations Orders (9P-orders), 
oOlanning documents, briefings, atc, 

The output wit!l be tn tne format desired by the 
requestor in addition to the regular reports generated. 

There will be a need for historical, current and 
projected data in the files. Here as in other modules and 
functional subsystems, a high degree of file interface is 
necessary. This will be required not only to update the 
ranging files, but also te formulate trends and decision aids 
for presentation to the CNO and his staff. In addition to 


preparing Standard reports, a number of submodules and 


specific applications will provide the capability of 
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displaying logically selected excerpts from the files to aid 
staff personnel in making briefings cr responding te "what 


if?” questions posed by the CNO or higher echelons. 


Readiness analysis module. The objective of this 
module is toa provide OPNAY with all data related te fleet 


readiness and training. The input te the data base will be 
from daily Operational Performance Data Reports (OPDATS) and 
Force Status Reports (FORSTATS), prepared by all overating 
units. The purpose of the module is to present an overall 
picture of the existing readiness and training condition to 
aid the CNOQ in performance of part of his mission, (j.e., 
maintenance of high readiness and training standards). 

One of the submodules included in this module will 
use the historical data for trend plotting and analysis of 
performance. This will be compared to the standards 
established by the CNQ to indicate areas of weakness 


requiring special emphasis. 


Intellignece module. At the present time, the 
CNOCOM/MIS designers have proposed no firm submodules or 
applications for this module. It is not yet clear what type 
of intelligence data must be provided and the security 
requirements which will ensue. However, it is a certainty 
that such information will be required for various decision 


processes. The sources wil] be both Naval and external. 
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taff Services Subsvsten 
The services provided by this module consist of both 
manual and automated methods. It is cesigned to provide 
administrative services to the OPNAY staff for the normal 
day-to-day business oneration. It consists of four modules: 
Administrative Information Control and Retrieval; Common 
Services; Automated Message Processing; and OPHAY Internal 


Services. (See Figure IV-4) 


Administrative information control and retrieval 
module. This is designed to increase the efficiency and 
effectiveness of mail and directive distribution and routing. 
It places emphasis on reduction of duplication of both effort 
and matertal. Included herein are such features as control 
and registry of incoming and outgoing pertinent corresponde- 
ence; a rapid retrieval capability for all controlled | 
correspondence; and an assistance service to ensure OPNAV 
directives have been prepared in the correct format and 


coordinated appropriately. 


Common services module. This module will provide 
suppert services that cross functional lines. These services 
will include, but are not limited to, the following: A 
reference system which will make needed documents available 
to the users; and, an automated correspondence service. 


The latter service will attempt to eliminate duplicate 
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typing and speed up the processing of outgoing correspondence. 
The computer will accept an unformatted draft, perform minor 
editing, store the draft in a computer storage area and 
provide the user with a printed draft in a format selected 

by the user. The correspondence can then be revised as much 
as desired by merely entering the changes into the computer. 
When all revisions have been made a final copy will be 

printed by the computer. For extremely critical correspond- 
ence requiring review by many offices, it is planned that 

this review will be done on remote Cathode Ray Tube 


(CRT) Terminals. 


Automated message processing module. This module 


will require interface with the Administrative Information 
Control and Retrieval Module to determine message routing 
patterns and controls. The module will be responsible 

for receipt of the incoming messages, conversion into 
routing format and making proper distribution of the 
contents. Dependent on the precedence/security classifica- 
tion combination, some of the addresses will receive the 
most urgent communications by CRT terminals. However, for 
those users not having access to the remote terminals, or 
for low precedence messages, the module will direct attention 
to copy control and routing. In addition, since messages 


requiring replies have specific timeframes within which the 
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response should be raleased, an automated service will he 
provided to alert tha holder of his unfulfilled obligation 


to avoid unnecessary systen “sluggistness." 


OPHAY internal services module. Owing to the past 
constant stete of flux regarding organization, office spaces, 
security clearance and eather general administrative items 

it is a requirement that such information should be filed 

to avoid unnecessary duplication of effort and inexcusable 
errors resulting from a lack of coordination. Some of these 
classes of infermation are: Organizational data, position 
descriptions related to jobs, security requirements and 


clearance lists, office space assignments, and telephone 


assignment controls. 


Proqrammina/Budgeting/Resourse Control Subsystem 

This subsystem is an extremely important segment of 
CNOCOM/MIS, t will contain financial and economic infor- 
mation required in order to make projections concerning 
every fact of Naval operations. It contains three basic 
modules te carry out this extensive mission, which are: 
Navy Models; Data Evaluation and Analysis: and Resource 
Control. (See Figure IV-5) 

The objectives of the Programming/Budgeting/ 
Resource Control (P/B/RC) Subsystem are to provide 
the tools to produce processed information that 


will assist the staff of the Chief cf Naval Opera- 
tions (OPNAV) to formulate Navy force objectives; 
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determine and identify the resources required to 
support these objectives; evaluate alternative 
choices of forcas and resources; evaluate imoact 
on the total Navy program of various guidance 
proposals, and decision; respond tn a tiniely 
manner to management information requirements; 
assess the degree of threat being satisfied by a 
choice of forces and resources; prepare, review, 
and approve required PPB (Planning Programming 
Budgeting) decision documents and reports; main- 
tain the Department of the Navy Five-Year Program 
(DNFYP); develop the Navy budget; prepare apportion- 
ments and funding allocations; and review the 
progress of program development by monitoring 
operations, commitments , obligations and 
expenditures. 


Data evaluation and analysis module (DEAN). This is 
a supporting module. It provides the means whereby data 
regarding manpower material and money can be collected, 
validated, analyzed and used as input to the IDB. It will 
further have the ability to generate quantifiable data from 
certain information sources and assimilate it for use by 
the Havy Hodel Hodule. As may be surmised from the name 
of that module, the input which is prepared by DEAK for 
the Navy Model consists of a maze of econonic and inventory 
contro] variable factors. These vartables have been 
grouped into families which created six submodules. 

The Operational Variables Submedule will describe 
the requirements related te the mission, the operating 
characteristics of the unit or piece of equipment and the 


tempo of operation. 


Miptd., p. 40. 
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The tnventory Variables Submodule refers to the 
quantities of material and manpower in use, and a projection 
of anticipated less of wen by attrition and various other 
factors regarding both men and material. 

The Procurement Variables Submodule pertains to the 
abtainment of facilities, items of material or manpower 
through purchase, construction, modification or (in the 
case of manpower) through training. 

The Industrial Variables Submodule describes the 
capabilities of the national economy, the industrial complex, 
and the labor force required to enhance the force structure 
in support of the procurement of materials or manpower, 

The Support Variables Submodule refers to items of 
direct and indirect support required to maintain the force. 

The Cost Variables Submodules identifies cost 
relating to the items of information or factors included in 
the other family grouns of the preceding variables. 

It had been anticipated by the data base designers 
that the data required by the foregoing submodules woutd 
be held in the IDB. toewever, it now seems that the infor- 
mation to be accumulated will be extremely massive. - A 
more feasible way will be te stere most of the information 


outside of the IDB in association tables readily accesstbie 


linterviews with Sarah Pillar, op. cit. and 
D. C. Foster, op, cit. 


7 
‘ | A - 
| bald 
_——- 
<= y 


mite: Ge ie 24 vs Corie Glee eet of 
2G aren! errs bor or teal 

eee ie) tet) eet a Ge 
~ ‘eee ery, 0 1 le om ee eigen: 
wmleawe Ot) eal §) tee Si he «fh wae Prayetey) tom 
Se eo ee i. oe lo 


» - 


f = 


Aine . weite* Abd atin Laer? 
——— ee rere Ur 





94 


by use of linkages provided in the unit tnformation reccrds 
and the tables. The linking will he coordinated by the Data 
Ofrectery and Dictionary Module File. This is enttrely 
cependent upon availability of adequate file manipulation 


software, 


Navy model module. The intent of this module is 
to provide a neans to accumulate aggregate data pertaining 
to the total structure of the Navy. Such information would 
include factors and algorithrs whitch may be drawn upon to 
compute quantified responses to questions derived by the 
CHO, OPRAY or higher jtevel external reguestcrs such as JCS, 
SECHAY or SECDEF. | 

Some of the capabilittes provided hy the Kavy Model 
Modute will be: A single source of tnformation for atl 
factors pertaining te the previously cited P/C/RC objectives; 
ability te manipulate algorithms and equations related to 
given sets of factors for the purpose of attaining 
"ootimization"; a means of evaluating situations and dis- 
playing risks in quantifiable terms; the ability to 
automatically update constant factors when analysis of 
historical data finds it necessary; and the ability to 
measure program progress in terms of time and nilestones. 

In the past, the CHO and the Navy Comptroller 


(NAVCOMPT) have been noticeably siow in resnending to queries 
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concerning bucget cr pregram watters which have been 
received from SECHAV, SECCEF of Congress. | in the future, 
the Kavy hocei Medule will provice the neans to compile 
responses to these “what if?" type cf questions in a matter 


of minutes. 


Resource control module. While the DEAH collected, 
validated, analyzed, and stored the data needed by this 
subsystem and the Navy Kodel Module manipulated the data 
and factors to derive a response, this module will primarily 
act to support those modules, This support will include 
such tasks as creation of a central file for appreved 
planning and cost factors used by the subsystem, and 
providing information for timely responses to cyclical 


requirements placed on the P/B/RC Subsystem. 


Management Suosysten 
The Management Subsystem will provide information 


to the CNO and OPNAV to support the multitude of programs 
with which the Navy is involved. It will perform various 
analyses such as program reautrements determination and asset 
status maintenance. It will interface with every subsystem 
in CNOCOM/MIS and possibly every module. Pata will be 
provided to the Command, Planning and P/B/RC Subsystems by 


linterview with Captain Jack Cockrell, U. S. Navy, 


Head, Program Budgeting Review Branch (OP-904), hashingtonr, 
D. C. on November 13, 1970, 
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this subsystem. In addition, it will utilize the other 
subsystems to extract, evaluate, anelyze and aisslay infor- 
wation pertinent to any selected module employed by the 
Nanagement Subsystem, 

Similar to the P/B/RC Subsystem, the scope of this 
subsystem is divided by the Mavy activities which it serves. 
Each of these functions have heen identified as a module 
which follow: Ships, Aviation, Manpower, Support, Communitca- 
tions, Inteliicence, kesearch and Development, Warfare, and 


Special Programs. (See Figure I¥-6) 


Ships module. Two subnodules are contained within 
this module. The one covers the area of ships management 
while the ether encompasses simulaticn models for various 
type of ship employment scheduling. 

The Ships Management Submodule pertains to the status 
and inventory of shins, small boats and service crafts. It 
will handle informaticn concerning construction programming 
and the execution of same, as well as the requirements for 
all of the vessels indicated above. 

The Ships Simulation Submodule embodies the attack 
carrier (CVA) deployment scheduling model and the amphibious 
warfare operations analysis model, 6oth models are dependent 


upon variables supplied Dy tne Naval Systems Commands. In 
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addition, it will require interface with the Planning, Command 
and P/B/RC Subsystems, 


Aviation module. This medule is similar to the ships 
module since it will perform the same sort of cata collection, 
manipulation and reporting for all aircraft and their funce- 
tions. It is composed of three submodules and a total of 
twenty applications. 

The principal ebjectives of this module are to 
previde: An up-to-date reporting svstem of all aircraft 
including readiness status and activity; a comparison of 
planned versus actual aircraft flying hours; projected air- 
craft procurement spare parts and rework recuirements; 
projected base, persennel, trainina and facilities require- 
ments; allocation of naval airspace; and analysis and gaming 
capability for managewent/spectal projects. These are but a 
few of the applications assigned to the Aviation Module, In 
the accomplishment of these tasks the system will receive a 
myriad of periodic raperts from all levels of management 
(i.e., operating level, squadron, type commander, fleet and 
systems commands). It will collect, validate and analyze 
this datas; and generate many reports which are now being 
orepared Sy various CPMNAV offices with less than cocerdinated 
effort. Needless to say, accuracy currently suffers consider- 


ably owing to the Tack of an ID8 from which to draw iaformation. 
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The rapid technological advances in the field of 
aviation and the hichly mobilized nature of the aircraft 
itself have caused much of the aforementioned cuery-response 
problem in the recent past. Fer that reason, one of the 
primary puroeses cf this module ts to provide a feasible 
totel aircraft erocram te the P/8/RC Subsystem, All? perti- 
nent information will be contained efther in the I0@ or the 


UIM which are readily linked for real-time operation. 


Nanpower/persornel module, The importance and poten- 
tial of this wodule to assist the CNO in developing short 
and longa rance manpower requirements is overwhelmine. As a 
module, it will interface with automated manpower systems 
already ir existence, While manpower/personnel is rot 
considered as cne of the three functional areas in the IDB, 
it will cress each cf these lines te update and interact 


with tne totel itd. cnlixe tne present system where there 


cr 


are no agagregate figures readily available, both military 
and civilian personnel will be included in the new system. 
This should eliminate redundancy ta accounting and maximize 
the utilization ef personnel with similar training and 
experience levels. It is anticipated that future require- 
ments may be projected as far as ten years, dependent 

upon the firm policy planning generated in the Planning 


Executive and P/B/RC Subsystens with which this module will 
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interface. Such a projection is contingent upon so many 
factors, including the technological improvements in weapons 
systems, the economy, etc., that it can be only a guess at 
this time. 

Needless to say, the personnel records will be quite 
extensive for each individual. Historical files will also be 
maintained, Aside from the statistical value of this module, 
it will also be possible for the Office of the Chief of 
Naval Information (CHINFO) to request biographical sketches 
of personnel. 

While there are six more modules in the Management 
Subsystem, as may be seen in Figure IV-6, it appears that 
the reader will be able to surmise, from the preceding 
descriptions of the Ships Module, Aviation Module and the 
Manpower/Personnel Module, the general plan of this subsystem, 
Therefore, only a synopsis of the remaining modules will be 
mentioned to emphasize the depth which has been designed 
into CNOCOM/MIS. 

The Support Module contains information pertinent to 
all facilities, material and transportation. Material in 
this sense pertains primarily to petroleum, oi] and lubricants 
(POL), conventional ordnance, and items specifically selected 


for review and analysis. 


The Communications Module is concerned primarily 


with the problem of data exchange. There will be direct 
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interface with an existing system, Naval Communications 
Command/Managenent Infeorwetior System (MAVCOMM/MIS\, in 
the accerplisiment of this module's missien. 

The Intelligence Module will assist OPNAY in the 
development, coordination and promulgetior of polictes, 
plans and programs for the intelligence and security 
activities within tne Navy. 

There has been little effort expended on the Research 
and Development (R&D) Module at this time. This is due to 
the fact that the planners and designers readily recognize 
the wide range included in R&N but did not feel that this 
module could be adequately researched in the time allowed 
for the design of CNOCOM/MIS. A much broader investigation 
into the needs of 2&0 is planned for the future. 

The Warfare “Module will strive to develop techniques 
and procedures Yor both offensive and defensive forces. The 
forces includes Anti-submarine warfere (ASW), strategic 
missile and weapon systems, and submarine. 

The Srecial Programs Module will dtrect attention 
te three unrelated tut important areas, It contains a sub- 
module for information concerning the Military Assistance 
Program (MAP); cne for Offshore Activities, which will 
orevide support for the estatlishrent of ocean surveillance 


standards; ene to provide guidance in the development of a 
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Navy-wide integrated automatic data processing (Ap?) 


information system. 
CROCOM/MIS AS AM OPERATING SYSTEM 


The entire CHOCOM/MIS concept has been laid out and 
the Subsystems with their respective modules have been 
briefly described, Although it is entirely feasible for the 
non-functional subsystems tu operate as a separate entity 
incgependent of the functional subsystems it must also be 
realized that such a condition occurs only during file 
maintenance operations. Even in thease operations there is 
a considerable amount of tnterdependency which exists 
between the varftous non-functional subsystems and the 


modules. 


storage Capability 
A comparison of the CNOCOM/HIS ebjectives listed in 


Chapter II, and the objectives of the individual non- 
functional and functional subsystems, reveal that all objec- 
tives are in complete consonance. 

There is cne area of methodology that tends to 
detract from the original design. That is the concept of 
an integrated data base, The approach selected by the 


} 


analysts, however, was one of optimization. Since they 





linterview with Sarah Pillar, op. cit. 
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recognized that it would be infeasible, with respect to 
equipment cost, to canstruct one mammoth IDB, they chose 
the option of abbreviatine the IDS and generating linkages 
(described in Chapter III) in order to retrieve any data 
held in any system file. fothing has actually been lost 
by this concept. All tnformatieon which ray be needed in 
real-time will reside In separate files on direct access 
devices of varying access speeds. The storage device used 
is dependent upon the normal priority of the user, The 
IDB will reside on the smallest fixed-head drums since its 
content is te be retrievable at the highest rate of speed. 
The next level of data would be stored on the laroer fixed- 
head drums followed by the next lower level on movable- 
head drums. Tre lowest level of data to receive direct 
access treatment will be stored on disc files.! 

It should be readily apparent from a review of 
Appendix F that access time will be far from slow in 
CHOCOM/MIS since the discs are the slowest directly 
accessible devices used. However, in an effort to compen- 
sate fer the need for levels ef data accessibility the 
designers and analysts at HAVCOSSACT are reviewing a 
storage hierarchy plan introduced by tne Rome Air 

"Waterview with D. C. Foster, Head, Systems Design 


Branch (Code 10), U. S. Naval Command Systems Support 
Activity, Washington, ). €. on January 21, 1971. 
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Develonment Center, Roma, %. y,! This system records the 
access frequency on each assessible element and automati- 
cally transfers the data from one storage device to another 
depending on the speed of access required for optimum 
effectiveness and efficiency. Such a system would readdress 
and move either data elements or whole strings cf data 
automatically as required by the level of need. 

Tape storage will be used fer all historical files 
which are not required for real-time corputations and/cr 
analysts. in adettion, some active files which are expected 
to be recuired periodically to interface with the IDB, but 
which ere not recutirec for real-tinpe responses, will also 
be maintained on magnetic tape. Fn example of this latter 
type ceculd be the varfable used to represent the economy's 
industrial complex. This information may te updated weekly 
or monthiy at which time the "trigger" elements previously 
described in Chapter III would cause other factors contained 


in the P/®/RC Subsystem to be updated. 


System Use and Maintenance 


The plan for construction of the IDB has teen 
previously described. Assuming now, that the system is 


operational there are a number of principles which must be 
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established in order to perform perpetual file maintenance 
and to receive, process and respond to user requests. 

Primary users of the system will he equipped with 
remote terminals which may be efther CRT or teletypewriter, 
depending upon the type/stze of display normally required 
and the anticipated rate of traffic through the terminal. 
File maintenance traffic, unless it fis necessary for updat- 
ing factors and data needed in real-time, will not be 
considered when projecting the terminals expected throughput. 
The reason for this is because many of the Data Sponsors who 
supply vast amounts of information to the IDB and peripheral 
files, do not require immediate response to their queries. 
The input and output needs of these users will be satisfied 
through the Customer Services Branch, (#.¢e., the Navy Infor- 
mation Center-NAVIC), Thete will be a U-9300 Remote 
Terminal located at “AVIC in addition to the existing com- 
puters which are: An IBM-7090, and [8M 1401, and IBM 1416, 
and an I8M-36G6/29. None of these computers will be devoted 
to CNOCOM/MIS applications but they wiil have the capability 
of interfacing with the U-1108 through the U9300 in order 
to perform specific functions for CNOCOM/MIS. 

Since one of the foremost tasks ef the designers, 
analysts and programmers of an information system is to 
maintain the inteuvrity of the data base, CNOCOM/MIS will 


initially utilize the MAVIC Computers to perform a majority 
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of the validations before allowing any information which will 
alter the data base to gain access to the IDB and related 
files. This will also mean that input data which is initi- 
ated from a remote terminal in a htgh level staff office 

will first be subjected to validation on a NAVIC Computer 
before it is transmitted to the U-1108 for entry into the 

IDB complex. As the system emerges and settles down, the 
validation should be condensed requiring less computer time 
and the colder I8M machines will be phased out, Queries on 
applications which do net update the files will not require 
such a rigid preview and will be permitted to access the 
U-1108 directly. At the present time, the exact quantity 

of remote terminals to be used is not known, but the designers 
Of CNOCOM/MIS feel that about 15-18 such terminals may be 
feasibly serviced without increasing excessive system 


overhead, | 


Priorities and fueueing 


Jobs entering the management information system are 
temporarily placed in a job queue which will be centrolled 
by the operating system. The queue will reside on one of 
the floating-head drums. 

The software must efficiently place jobs in queue, 


Scan and evaluate the jobs in queue, select jobs for 


Vinga, 
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processing, and delete completed jobs from the queue. It 
will arrange the jobs in the order which they are to be 
completed dependent upon the assianed, 

The operating system will ensure that low prtorities 
are handled within the timeframe required, After a low 
priority job has been passed over a number of times, and 
the computer clock appreaches the job's deadline time, the 
operating system will eutomatically raise the priority of 
the job to force it ahead of other pressing jobs. This 
eliminates the possibility of having a low priority job in 
queve for an unreasonable period of time. The ability of 
the operating system to supervise job queues determines the 
effectiveness of the system. The saturation point for job 
queueing is a function of the arrival rate, service time 
and priority of the jobs entering the queue. It is the task 
of the operational software to allocate available equipment 
time to jobs in order to optimize customer satisfaction. 

The effective queueing of jobs depends on a well 
defined ortority system. Some of the more sophtsticated 
executive systems have priority routines containing up to 
160 levels subsequently grouped into three or four categories, 
Norman Enger outlined what he considers to be a typical 


} 


choice of job priorities’ as follows: 





Tworman L. Enger, Putting HIS to Work, op, cit., p.&5. 
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(1) Emergency priority--run immediately. 

(2) Background priority--assigned to jobs that 
would use low speed peripheral devices at their maximum 
speed, 

(3) Special priority--used for short jobs which 
may be interwoven with existing jobs. 

(4) Input/output priority--assigned to jobs that 
will keep the I/0 Channels fully occupied, 

(5) Compute priority--used for jobs consisting of a 
significant amount of mathematice] computation (process-~- 
bound). 

Maximum use of peripherals produces system efficiency. 
Therefore, since computer power is abundant in relation to 
peripheral power, jobs with compute pricrity have the lowest 
priority. 

In the U-1168 Executive System (EXEC-8) there will be 
three basic levels of pricrity: Real-time, demand, and batch. | 
Real-time will require servicing the program to get the 
results back te the source of inquiry in time to effect on 
going events. Demand priority exhibits a need to be 
processed in a relatively short timeframe. The deadline 
time assigned, or allowable wait time, in relation to the 


input time becomes extremely critical in this priority level. 





Vinterview with BD. C. Foster, op. cit. 


ee ~ 
o= _ Ne. | ~ 
yo * 








q 
— SS —_—— - -_ a : 
os > =i a 2 ~ “ — 


’ ee ve ’ <<. a 

ee FI « a. _ 

fom ow adr et Te ttt 

Se ee re et oe ee t 

ae eee ee) |e 
= ee ee i © «heer 

” © wlaitte mF OP mien semen nah 


=e 2 iaetiee 168 {ae lias Wwe —- — if 


+ lt ——a -~ “Ste omememeer 














. 





























109 


A demand job in queve may only be preempted by a real-time 
job or another demand job having a shorter completing time- 
frame. The batch priority will be assigned to jobs require 
ing overnight service. These, too, will be assigned a 
deadline time and as that time draws near tne priority 


will be raised to insure completion.. 


COMMENTS 


Given a system consisting of the complex sub- 
systems and the hardware configurations as discussed in 
the preceding chapters, the user is still confronted with 
the day-to-day task of man/machine interfacing. 

The CNOCOM/MNIS designers are currently attempting 
to provide a system which will require minimal data 
processing experfence and knowledge. It is anticipated 
that the user will be able to query the ID8 through a 
remote terminal using near English language statements. He 
will need to know only the English names of the data elements 
he wishes to retrieve. Further, if the user is not aware 
of what the IDB contains, the system will assist him by 
furnishing on the terminal what is available within the 


parameters established by the requestor himself. 
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The user must have the capability to both auery 
and update files by either direct access dialogue or 
batch processing. This capability will in turn necessitate 
retrieval or updating of multiple files concurrently. 

Reports are never useful and efficient unless they 
give the information required by the user in a format 
intelligibla to him. CNOCOM/MIS would not be fulfilling 
this need if it could not provide a means of free form 
report generation which is able to select only that 
information destred hy the user in his desiaqnated format, 

Considering the advancements built into third- 
generation hardware and the design features of CNOCOM/NIS, 
it is not practical to contemplate the use of second 
generation compilers such as COBOL, FORTRAN or RPG for this 


level of file management. 





CHAPTER V 


SUMMARY 
QBJECTIVES AND BENEFITS 


The primary purpose of CNOCHK/NIS is te improve the 
command/control and information handling capabilities of CNO 
and of the OPNAV staff through the use of advanced data 
processing equipment and techniques. CNOCOM/MIS will help 
provide the timely, high quality information needed to 
efficiently support the decision-making, planning, programming, 
budgeting, and coordinating functiens tn OPNAV, In general, 
1t will assist Navy top management in: setting objectives, 
shaping and evaluating alternative strategies, making decisions 


and measuring results. 


Common CNOCOH/HIS Benefits 
With the attainment of the overal? CNOCOM/MIS 


objectives listed in Chapter II, these anticipated common 


benefits will folTow. 


Accessibility of information. The users, OPNAYV staff 


members, will be able to locate information readily for their 


decision-making. It witi be provided by subordinate commands 
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via communications links and stored on mass storage devices. 
The information will be presented to the user by means of 
remote display units er through the service center as 


appropriate. 


Integration of information. integrated information 
will eliminate duplicate reporting and conflicting data. It 


will permit use of a wider range of information to all users. 


Reliability of information, The data sponsor system 
will Yead to more timely and reliable information for all 
staff elements. Security and limited access protection of 
the data files will be maintained by design of the mainten- 


ance software. 


Distribution of information. The flow and distribu- 
tion of information into and out of OPNAV staff offices will 
be considerably improved. Reports currently received or 
transmitted by the staff will be consolidated, where possible, 


decreasing the overall flow. 


Information storage and processing capability. 
CNHOCOM/HIS will provide the automated capability to acquire, 


store and manipulate large quantities cf data necessary for 
effective decision-making. Many applications will be 


processed concurrently causing more timely report generation. 
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case of user/system interface. The OPNAV staff, 


users will be able to communicate with the system and to use 
its capabilities fully with extensive ADP or information 
system training. fesides remote terminal accessing and 
manipulating, there will be the ability to pre-test the 
sensitivity of data and its effects on decisions prior to 
actual live processing. This will efford either model or 


variable adjustment, es required, before implementation. | 


Specific CNOCOM/MIS Benefits 


Waite the foregoing common benefits will be realized 
by all users of CHOCOM/MIS, there are a number of anticipated 
benefits unique to the vartous subsystems. These are 


foundations for the total system and worthy of reemphasis., 


Decision-making process. The P/B/RC Subsystem is a 
pioneering effort to provide more adequate information for 
the planning, programming and budgeting (PPB) specialists. © 
The crux of PPB is the systematic evaluation of alternatives 
in the performance of cost-benefit analysis. This processing 
will involve: Identification of naval objectives; the 


derivation and tdentification of alternative courses of action; 


ee 





Tus s. Department of the Navy, CNOCOM/HMiS System 
Design Proposal, op. cit., pp. 224-225, 
2 Interview with KR. oN. Schauer, Technical Assistant, 


CHC Information System Branch at the Pentagon, Washington, 
D, C. on January 20, 1971. 
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the estimation of total costs of each alternatives; and an 
estimation of expected results of each alternative. 

The primary benefits to be achieved by tmplementing 
the Manpower/Personnel Module center around the availability 
of more timely and detailed information for decision-makers, 
The establishment of a comprehensive data base of manpower 
management and personnel administration information will 
provide a singie source to a wide spectrum of staff? users. 
In addition, it will for the first time contain integrated 
data pertaining to both civilian and military personnel in 


the Department of the Navy. 


Data collection and use. The data base will not 


i a 





reside entirely in a single storage or processing device, 
but will be supported from several sites which are inter- 
twined by data transmission links. Although physically 
decentralized, the strict principles of data base manage~ 
went prescribed for CNOCOH/MIS will be prescribed by the 
centralized system, This witl result in: 

(1) Economies in file maintenance. 

(2) Standardization of data elements, records and 
files. 

(3) Savings in the high cost of input preparation 
by decreasing the number of {nputs and sharing common data 


among users. 
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(4) An improvement in information accuracy by 
Operation of all users from a common data base, 

Captain R. A. Jones, SC, USN, former head of the 
CNO Information Systems Branch, and architect of CNOCOM/HIS, 
made the following comment regarding the realization of the 
foregoing benefits: 

The plan for achteving CNOCOH/MIS objectives 

is evolutionary in concept. A minimum of three-to- 

five years is required for a Management Information 

System of this size to even begin to realize bene- 

fits of any magnitude, A well tnought out and 

realistic management plan accompanied by perserver- 

ance of top management will soon show progress 

that will gain momentum aS management acquires the 


expertence and confidence necessary to use this 
new tool, 


MEANS TO ATTAIN OBJECTIVES 


In order to reach the desired objectives of CNOCOM/MIS 
and to realize fully the anticipated benefits of the new 
system it is necessary to define predetermined milestones. 
These benchmarks Have been discussed individually in the 
preceding chapters as principles and procedures inherent 
to the various subsystems. The following is a consolidated 
recaptitulation of the overall system requirements determined, 
by the writer, to be cf prime impertance for cbhjective 


attainment: 





VR, A, Jones, Captain, SC, USH, “CNO Command 


Management Information System," Navy Management Review, 
March-April 1970, p. 20. 
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(7) The construction of a data base capabie of 
incorporating automated aWe hon -dteoha tbe information by 
means of a Data Ofrectery and Dictionary technique. 

(2) The ability to link the automated data files 
for retrieval and maintenance, and to nrovide a safeguard 
against possible breaks in the linkages. 

(3) The abtlity to index selective fields for 
retrieval and to perform extensive validation of all data 
Input to the data base, 

(4) To provide the capability of total file mainten- 
ance from a limited number of data sponsor inputs ({f.e., 
update all files affected by any single element change). 

(5) To allow for the entry, recording, processing 
and extraction of variform data. 

(6) To provide for an increased capability to 
interface CNOCOM/MIS with all of the existing software 
systems found to be basically compatible. 

(7) To provide for operational interface among 
the various existing hardware configurations and anticipated 
reconfigurations. 

(8) The development of a secure data communication 
network which will permit middle managers at the fleet level 


direct access to the data base, 
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(9) To permit OPNAV staff users, and eventually 
fieet users, to directly access the files by means of 
remote terminals and to manipulate data and/or extract it 
in the format desired, 

(10) To design a software technique which will 
guard orivate information by allowing access only to those 
found to be qualified. 

(11) evelopment of a priority and queueing system 
which will differentiate between real-time, damand and 
batch requirements while performing the joos within the 


timeframe allowed by the requestors. 


EXISTING CAPABILITIES 


The U+11038 and its peripheral devices will provide 
up to nanosecond speed for accessing, processing and 
displaying information. The central processing unit (CPU) 
is designed te accomplish multi-programming which is the 
concurrent operation of many programs. The dual processor 
(two CPU's) feature used for CNOCGM/HIS further expands 
the capabilities to allow beth CPU's to perform multi- 
rrogramming simultaneously while sharing the same executive 


program. | 





linterview with R. R. Whittington, UNIVA Consultant, 
Rashington, D.C. on November 11, 19790. 


aa OO ean Nee mr 





118 


Tha executive program (f£XEC-3) requires one bank of CPU 
storage, or 55,909 words. + n2 dual processing environment 
thereby conserves an entire bank of storage which can be 
devoted to operational programming. 

Modular software design working in conjunction with 
the multti-programming and multi-processing features mentioned 
above, makes it possible to utilize a feature known as 
reentrance. This 1s a technique by which multiple users 
employ common programs,or subroutines in order to conserve 
CPU storage. If a program is non-reentrant it is 
necessary to lay the entire progrém in core for processing 
which reduces available memory and the number of programs 
which may be serviced concurrently. 

Even with the increased capabilities of the third 
generation hardware and its executive system there remains 
an unfulfilted need to manipulate files more efficiently. 
Each program must be written to perform its own file 
processing. Such duplication becomes extremely costly both 
at program generation time and at run time. The EXEC-8 
was written to interface with COBOL. This compiler alone 
utilizes 40,000 words of core anc still does not provide 
adequate file handling or system interfacing features. 


R. R. Whittinaton, UNIVAC Consultant, further claims that 








linterview with D. C. Foster, op. cit. 


2 Interview with 0. C. Foster, op. cit. and with 
R. R, Whittington, op. cit. 
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the computer industry as a whele oversold the higher level 


1 He feels that there are two main inefficiencies 


languages, 
which were not adequately revealed to the businessmen: 

The use of a syntax reryt hive ADP orfentation by the user 
and the extensive need for core in relation to the meager 
file handling capabilities to be realized. 

Rhile the compilers have provided ease in writing 
programs to personnel with minimal ADP tratning, there is 
still a need for at least thet amount of basic tratning 
before man/machine dialogue is possible. Furthermore, the 
programmer must receive even more training if he is to 
profitably encounter a file-to«file interface. The computer 
software industry has acknowledged this problem and as a 
result the data management systems (OMS), sometimes referred 
to as file management systems (FMS), are now being perfected 


by numerous firms to fulfill this technological requtrement. 


A DHS/FRS OVERVIEW 


Having realized the shortcomings of the thire 
generation equipment, EXEC-8 and the existing compilers, 
NAVCOSSACT launched a comparative analysis of eighteen 
data management systems. The DMS's, previously cited in 


Chapter III, were initially evaluated against the following 





linterview with R. R. Whittington, op, cit. 
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criteria by the study group. In addition to the hardware, 
executive and compilers, the group established these features 
as basic requirements for the accomplishment of CHOCOM/HIS 


objectives. 


Mandatory Features 


1. Direct access of fields used as retrieval/ 
update arguments. 

2. Command macro languages for file description, 
maintenance and retrieval. 

3. On-ltine/remote capabflities for retrieval 
and update. 

4. Efficient use of immediate access devices 
for data base storage. 

S. Standard system formatted outputs and user 
defined flexible report formats, 

6. Implementation within a reasonable time at 
a reasonable cost. 


Desirable Features 


1. Multi-file capabfiity for both maintenance 
and retrieval or its equivalent. 

2. Hardware independent source language of 
implementation, 

3. Capability of interfacing with POL and AL 
coded programs for sophistocated applica- 
tions beyond the scope of the interval command 
languages. 

4. Input data validation. 

S. Data base integrity and access rights to 
the field level during simultaneous on-line/ 
batch processing. - 

6. Optional usage statistics to the field 
level. 

7. Conversational language capability for all 
modules, 

8. Capability to change the file description 
(without regenerating the entire field) and 
automatically maintaining the credibility of 
the data. 


‘i 


Ty. $. Department of the Navy, A- Stud pile. Evaluation 
of Data Management Systems, op, cits, pp. 1e-T7, 
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Seven of the systems survived the initial evaluation 
and were then subjected to a more detailed analysis. The 
technique used for this phase was developed by Informatics, 
Incorporated for the Air Force in 1967. 

Each ef the DHS's were graded against 279 criteria 
which made up the following categories: 

(1) file definition and structure 

(2) file creation and maintenance 

(3) query/extract 

(4) secess rights 

(5) query cutput presentation 

(6) extract output presentation 
Appendix oh contains the rating results ef each of the seven 
systems evaluated. 

The study concluded that no existing DMS in its 
present state was capable of supporting the CNOCOM/MIS 
concept. The group determined, however, that it would be 
feasible to enhance an existing system ta provide the desired 
level of support. The DMS selected, by the evaluation, was 
the Generalized Information Management System (GIM) developed 
by TRK Systems. 

The recommendation was approved by CNOQ and NAYCOSSACT 
was directed to proceed, The new hybrid was named DATAMAN ITI 





Vipid., p. 55. 









™ sie 1 5 
ae te fw ah Oe 
— arenes ail” ai 
eee | 


i == => oa tt a om 
AE ee et Oe cae Oy AR ome Ae: 


(se adtias” Ow 






122 


and is now in the proposal stage to fulfill the fellowing 


requirements: 


ae 


Command macro languages for file description, 
maintenance and retrieval. Englishe-like 
statements which facilitate use by personne] 
with varying levels of functional and data 
processing backgrounds. 
Selective indexing capability, 1.e. direct 
access of items used as retrieval/update 
criteria. 
Effective capabilities fer retrieval and 
update in both oneline and batch modes, 
tandard system formatted outputs and user 
defined reports of highly sephistocated or 
complex structures, 
Capability to maintain and/or retrieve from 
multiple files concurrently. 
Validation of input data. 
Capability for interfacing with programs coded 
in procedure ortented or machine oriented 
languages for computational functions beyond 
the scope of the command language. 
Data base security and privacy provisions. 
Conversational languages with tutortal aids. 
Optional usage statistics to the item Ttevel. 
Re-entrant precessing. 


CONCLUSIONS 


In view of the elaborate system design of CNOCOM/MIS 


requiring extensive files, modules, subsystems and systems 


interface as well as the near English language on-line 


qguery/processing capability, adoption of a data management 


system (DMS) fs not only justified but ts mandatory for 


system realization, Without the development and imptementation 





7 
DP. GeS, 


U. S. Department of the Navy, DATAMAT: TIT, op, cit., 
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of a DMS to fulffll the specific requirements of CNOCOM/MIS 
it would be tmpossible to fntegrate twelve subsystems of 
the magnitude of those described in Chapters IIT and IV inte 
an operational entity. With the dynamic combination of 
CNOCOHM/MIS design, the U-1108 system with EXEC-8, existing 
compatible assemblers/comptlers and DATAMAN III, the CNO 
and his staff will possess the highest level of data 
accessibility, processing and repert generation attainable 
at this time, 

However, considerable effort must be given to two 
weaknesses which will plague the system in the jong range 
if not corrected, The first of these 1s tne need for a 
secure data transmission media which can be used for classified, 
unclassiffed or varying decrees of privacy information con- 
currently, The second weakness is dependent upen successful 
accomplishment of the first. It is the need to provide 
the middle managers at the fleet headquarters level with 
direct access capability to the IDB at the earliest oppor- 
tunity. Without a timely exchange of information with these 
commanders of the “seagoing Navy" CNO will never achieve the 
ultimate responsiveness destred but will ". . . pour good 
money after bad attempting to perpetuate ‘second generation’ 
system concepts into third or perhaps fourth generation 


management information systems." 


oS TR ee Re ee We Wer en eet 


TRobert V. Head, "The Elusive MIS," op. cit., p. 26. 
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Missions and organization. The organizational 
Structure of the Offiée of the Chief of Naval Operations 


appears on the preceding page. The mission of each OPNAV 


Division is described below: 


(1). OP-01, Office of the Deputy Chief of Naval 
Operations (Manpower and Naval Reserve) = To implement the 


responsibilities of the Chief of Naval Operations for planning, 
programming, controiling, and appraising the Navy's 

military manpewer, non-material aspects of manpower support 

and the Navai Reserve. 

(b) OP-03, Office of the DONO (Fleet Operations and 
Readiness) - To implement the responsibilities of the Chief 
of Naval Operations in respect to the ocperations and readiness 
of the Operating Forces of the Navy, with the exception of 
the Military Sea Transportation Service, including their 
employment, training ena readiness for. war, 

(c) OP-04, Office of the DCNO (Logistics) - To plan, 
determine, and provide for the logistic support needs of 
the Operating Forces of the Navy, except for those areas 
elsewhere assigned, and to serve as the principal advisor 
and executive to the Chief of Naval Operations on the conduct 
of the logistic affairs of the Department of the Navy. 

(d) GP-05, Office of the DCND (Air) + To implement 
the responsibility of the Chief of Naval Operations in 


determining the requirements, force levels, and major 
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characteristics in the execution of naval aviation programs, 
their planning, preparation and execution; to advise on 
naval aviation matters; and to represent CNO in naval air 
operations involving relations with other government and 
civil agencies. 

(e) OP-06, Office of the DCHO (Plans and Policy) 

To develop and disseminate plans and policies, and serve 

as the principal advisor to the Chief of Naval Operations 
on Jotnt Chiefs of Staff matters and as the principal 
advisor to the Secretary of the Navy and the Chtef of Naval 
Operations on international politico-military matters, 
including foreien military assistance. 

(f) OP-07, Office of the DCNO (Development) - Te 
implement the responsibflities of the Chief of Haval 
Operations and to assist the Assistant Secretary of the 
Navy (Research and Development) with respect to coordination, 
integration, and direction of the Navy Research Development, 
Test and Evaluation (RDT&E) Program. 

(g) OP-90, General Planning and Programming Division 
Under the direction of the Director, Navy Program Planning, 
to develop and operate an integrated program planning 
system for the Chief of Naval Operations, assist in the 
formulation and administration of the operating budget, and 
implement the responsibilities of the Director, Navy Program 


Tanning with regard to Navy programs and plans related thereto. 
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(h) OP-91, Information Systems Division - Under 
the direction of the Director, Navy Program Planning, to 


exercise centralized coordinating authority over information 
systems and exercise necessary direction and control of 
information systems development within Bureau, Cffices, 

and Commands under the command of the Chief of Naval 

Operations tn order to effect maximum practical integration 

and promote effectiveness and economy ef ADP utilizaticen; 

to plan, develop and implement and integrated command and 
management information system for the Chief of Naval Operations. 
Information systems as used herein apply to management and 
command and control applications. 

(1) QOP-93, Long Range Objectives Group - Under the 
direction of the Director, Havy Program Planning, to support 
the Chief of Haval Operations in his reles as principal 
naval advisor and as principal naval executive, with respect 
to the long-range objectives of the Navy, including those 
pertaining to the total strategic, tactical and technological 
future of seapower and other maritime-related matters 
involving the security and well-being of the United States. 

(J) OP-96, Director Systems Analysis Division - Under 
the direction of the Director, Navy Program Planning, to 
provide the Chief of Naval Operations with a system analysis 
capability to evaluate the relative effectiveness of 
alternatives in program and program proposals and thereby 


to assist in the decision making process; to manage the CNO 
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Study Program and coordinate this program with other Navy 
Department study efforts; to review and evaluate study 
results; and to implement the responsibilities cf the 
Director of Havy Program Plarning for conducting scientific, 
analytical and technical studies through the medium of the 
Center for Neval Analyses. 

(k) OP-092, Office of Navai Intelligence = To 
serve as the principal staff adviser to the Secretary of the 
Navy and to the Chief cf Naval Operations on intelligence 
and security plans and policy matters; to implement the 
responsibilities of the Chief of Haval Operations to develop, 
coordinate and promulgate polictes, plans, and programs for 
intellfgence and security activities of the Department of 
the Navy; to represent the Department of the Navy on the 
United States Intelligence Boards; and te advise and assist 
officials of the Department of the Navy in matters of 
protocol and liaison with foreign efficiais, 

(1) OP-094, Office of Haval Communications - To 
exercise, as the communications executive to the Chief of 
Naval Operations, overall authority throughout the Department 
of the Navy, in matters pertaining to communications, 
cryptology, and the radio frequency spectrums to determine, 
review, validate and approve requirements for the Department 
of the Navy in these areas. 

(m) OP-095, Office of Antisubmarine Warfare Programs 


Aina ola nares ast Ea nial 8 


To exercise, for the Chief cf Naval Operations, centralized 
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directive authority over all antisubmarine warfare planning, 
pregramming and appraising, in order to ensure an integrated 
and effective antisubmarine warfare effort; to implement 

the responsibility of the Chief of Naval Operations in ail 
ASW matters pertaining to the determination of requirements, 
including development, the selection ef work to be performed 
by the Chief of Naval Hatarial, and the avpraisal of work 

in progress for military worth and readiness; and to act 

for the Chief of Naval Operations in all matters affacting 
antisubmarine warfare, 

(n) OP-097, Strategic Offensive and Defensive 
Systems ~- To exercise, under the Vice Chief of Naval Operations, 
as the strategic offensive and defense systems executive 
in the Office of the Chtef of Naval Operations, centralized 
coordination over all strategic offensive and defensive 
force planning, programming, and appraising in order to 
ensure integrated and effective Navy strategic offensive 
and defensive applicable orders and directives, the 
responsibility of the Chief of Naval Operations in all 
Strategic force matters pertaining to the determination of 
concepts, vulnerabilities, requirements, including develop- 
ment, and the appraisal for military effectiveness of work 
{in progress. | 

(o) OP~098, Office of the Assistant Chief of Navai 


Operations (Safety) - To act for the Chief of Naval Cperaticns 
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with respect to the direction and supervision of the planning 
and implementation of safety programs throughout the Depart- 
ment of the Navy (except for these areas wherein such 

safety resoonsibility rests with the Commandant of the 

Marine Corps); to act as principal advisor to the Chief of 
Haval Operations in all matters concerning safety. 


(p) OP-09B, Assistant Vice Chief of Naval Operations/ 
Director of Naval Administration ~ To execute the administra- 





tive, management, and organization functions pertaining to 
Shore-based activities and facilities to provide staff 
assistance to the Chief of Naval Operations; to provide 
required administrative support to OPNAV; and to serve as 
executive te the Chief cf Naval Operations. 

(q) OP-007, Chief of Information ~ Also as Staff 
Assistant to the Secretary of the Navy, advises the Secretary 
and Chief of aval Operations on polictes and methods 
relative to public affairs aspects of operations and 
activities. He coordinates Marine Corps public information 
matters with the Office of Information. He keeps the public 
informed on the activities of the Navy as an instrument 
of national security, and disseminates to naval personnel 
appropriate information on policies and programs of the 
Navy Department. 

(r) OP-008, Office of the Naval Inspector General 
To inspect, investigate, or inquire into any and all matters 


of importance to the Department of the Navy, with particular 
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emphasis on readiness, including but not limited to: 
Effectiveness, efficiency, and economy; personnel require- 
ments, morale, welfare, end discipline; command relationships 
and organizational structure; management practices, including 
naval program development and cantrol; and to serve as 

the principal advisor to the Secretary of the Navy and the 
Chief of Naval Operetions on Department of the Navy 


inspection matters, 
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